MongoDB vs. SQLite vs. CrateIO

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.

The everything store.

Mongo powers our data

Used to be MySQL, but once moved to MongoDB, everything just speed up dramatically, data became pretty and easy to work with. Sophisticated aggregations allow us to run complicated analytics anytime as easy as possible.

Store image metadata.

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.

Our NoSql data storage. Provided to us through Modulus.

Main storage

We use MongoDB as the database server for all infra configuration/settings.

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 is only used as session storage since storing session in Firebase is not feasible.

로그성 데이터는 mongodb 에 기록됩니다. 뛰어난 성능이 강점입니다만 NOSQL 의 특성을 이해하지 못하고 사용할 경우에는 오히려 독이 될 수 있습니다.

Big datasets not likely to need joins with another dataset go in Mongo to offload Postgresql

As primary database

in conjunction with Meteor, database alternative

This is our DB.

So much more flexible than SQL …

Primary product data store

Primary app data store.

We use Mongo for persistent storage and retrieval. We also use a nifty Mongo ODM, Mongoose (available from NPM), to model our schemas and connect to Mongo on our private VLAN.

We support Mongo databases so that developers can interact with their data.

Main database

Our main datastore

Our data storage, for the most part is handled by a set of MongoDB storage clusters handling all the persistent information needed for our apps.

Hosts the unstructured data for each event that comes into the system. Also maps the event to each individual job or pipeline that gets spun off. All relevant persistent data is currently stored here.

Data layer

Backend account data storage.

In conjunction with Mongoose.js as a Node.js interface for MongoDB, I utilize this service to store user/feedback information.

Data storage of ITFrame

Notifications and analytics.

Great data store for JSON objects, which is mostly what I need.

Document oriented distriubted storage

Because you don't know what data you will be querying for. Perfectly suited for rapid prototyping. Altering tables in traditional, relational DBMS is painfully expensive and slow.

Performance is not great though. Ah who cares!

MongoDB is used as a datastore for accounts and users and underlying storage engine for databases.

Models in Agile Toolkit support NoSQL databases including MongoDB.

Main data storage, Has a secondary cache and stores our time series reports.

MongoDB is our prefered document store for pretty much all non-relational-heavy development. MongoDB scales beautifully and provides us with very polished api's and drivers. Easy to use, flexible and scalable.

some logger with it's own isolated collection

backend data store container

Replicated high-availability and high-performance database.

Backend of the app

Used Mongodb for web application development.

Saving Application data

Yes, we use Mongo

Backend server

MySQL was yesterday... MongoDB rocks. Check out s for smartdata on npm for MongoDB with TypeScript support.

Primary document store backend for the API

Unstructured No-SQL DB was important as deal with several different devices.

The backend for Parse Server.

System's main database

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.

Auxiliary storage for service data and settings. GridFS as storage for binary data

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.

Schema-less, JS in the console, flexible, fast, and pairs well with node/Mongoose.

타임라인 반응 데이터 및 로그 데이터 저장

OpenStack 내부의 메터링 서비스 데이터 기록을 위한 DB로 잠깐 사용했었다.

다이어리 앱의 사용자 및 다이어리 데이터는 MongoDB로 관리합니다.

Data storage.

The Geospatial features are the easiest to get up and running and easiest to scale beyond single servers. On top of that NoSQL allows us to iterate features at the speed of light.

We use Mongo for storage

Backend and analytics database.

Easy to develop with, can make changes to schemas easily.

Persistence database to store any data

Native integration with meteor

We used MongoDB to implement a filesystem abstraction for the application (i.e. each user has his/her own home directory and can share them, etc.)

Primary DB

For document (attachments) storage and associated metadata

Easy to use for small projects

Persistence Database

NoSQL of choice

MongoDB is used to store most of our data, both user-related (e.g. documents, contacts etc.) and global.

Leading document (JSON) database

We use MongoDB as our main NoSQL repository for data.

Out main storage.

Stores database items in document format. Doesn't require a schema declaration.

Mandatory database in meteor.js, stores user profiles

If we encounter multi-level or complex objects, we usually go with mongo/document/cosmos DBs. Getting better in detecting such objects and moving them here.

Used for testing.

Used on our client(s)

Gestor de base de datos para el almacenamiento de datos en aplicaciones móviles.

For smaller internal tools we build that requires easy local storage.

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

DB backend, when required

Local DB on iOS devices

For V.1.0 all data is stored using phonegap SqliteStorage plugin,

We support SQLite databases so that developers can interact with their data.

Storage of data for both mobile apps and native apps

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

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

Database for mobile development

Local Django unit testing

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.

Datasource for CoreData

Used SQLite with Ghost for Blogging service, both are free.

SQLite is used in the Android application, to store data on the mobile

basic

Only on local projects, nothing in production :-)

Inline DB on clients and apps.

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.

Mobile app local databases.

For support reasons not relay used