Used MongoDB as primary database. It holds trip data of NYC taxis for the year 2013. It is a huge dataset and it's primary feature is geo coordinates with pickup and drop off locations. Also used MongoDB's map reduce to process this large dataset for aggregation. This aggregated result was then used to show visualizations.

MongoDB fills our more traditional database needs. We knew we wanted Trello to be blisteringly fast. One of the coolest and most performance-obsessed teams we know is our next-door neighbor and sister company StackExchange. Talking to their dev lead David at lunch one day, I learned that even though they use SQL Server for data storage, they actually primarily store a lot of their data in a denormalized format for performance, and normalize only when they need to.

While the huge majority of BI data comes from 3rd-party sources, some pieces require ad-hoc sources - this is largely where Mongo comes into play. Views such as "Activity Log" need on-the-fly recordkeeping that's best manually entered; considering that fetching from a task manager API will paint an overwhelming or inaccurate picture of the month's activity.

Nearly all of our backend storage is on MongoDB. This has also worked out pretty well. It's enabled us to scale up faster/easier than if we had rolled our own solution on top of PostgreSQL (which we were using previously). There have been a few roadbumps along the way, but the team at 10gen has been a big help with thing.

We build queries in PHP with DSQL that work with SQLite. We also have SQLite data controller, so that you can build SQLite-based models.

Used during the "build process" of Coolfront Mobile's Flat rate search engine database. Flat rate data that resides in Salesforce is transformed using SQLite into a format that is usable for our mobile Flat rate search engine (AKA: Charlie).

We are testing out MongoDB at the moment. Currently we are only using a small EC2 setup for a delayed job queue backed by agenda. If it works out well we might look to see where it could become a primary document storage engine for us.

RDBTools is a self-hosted application, and it is important that the installation process is simple. With SQLite, we create a new database file for every analysis. Once the analysis is done, the SQLite file can be thrown away easily.

All the dynamic data (i.e.: jobs) is stored in a simple SQLite database.

Все динамические данные (вакансии) хранятся в простой SQLite БД.

There's really no call for something heavier for this site. SQLite is simple, easy to use and quite reliable given its age.