MongoDB vs. SQLite



Hacker News, Reddit, Stack Overflow Stats

  • 623
  • 713
  • 109K
  • 3.74K
  • 10.1K
  • 64.4K

GitHub Stats

No public GitHub repository stats available

Description

What is MongoDB?

MongoDB stores data in JSON-like documents that can vary in structure, offering a dynamic, flexible schema. MongoDB was also designed for high availability and scalability, with built-in replication and auto-sharding.

What is SQLite?

SQLite is an embedded SQL database engine. Unlike most other SQL databases, SQLite does not have a separate server process. SQLite reads and writes directly to ordinary disk files. A complete SQL database with multiple tables, indices, triggers, and views, is contained in a single disk file.

Want advice about which of these to choose?Ask the StackShare community!

Pros

Why do developers choose MongoDB?
Why do you like MongoDB?

Why do developers choose SQLite?
Why do you like SQLite?

Cons

What are the cons of using MongoDB?
Downsides of MongoDB?

What are the cons of using SQLite?
Downsides of SQLite?

Pricing

How much does MongoDB cost?
MongoDB Pricing
How much does SQLite cost?

Companies

What companies use MongoDB?
2567 companies on StackShare use MongoDB
What companies use SQLite?
385 companies on StackShare use SQLite

Integrations

What tools integrate with MongoDB?
40 tools on StackShare integrate with MongoDB
What tools integrate with SQLite?
15 tools on StackShare integrate with SQLite

What are some alternatives to MongoDB and SQLite?

  • MySQL - The world's most popular open source database
  • PostgreSQL - A powerful, open source object-relational database system
  • Microsoft SQL Server - A relational database management system developed by Microsoft
  • MariaDB - An enhanced, drop-in replacement for MySQL

See all alternatives to MongoDB

Latest News

Sharded replica sets - MySQL and MongoDB
This Week in Data with Colin Charles 28: Percona Liv...
Performing a Live Migration from a MongoDB Cluster t...
orchestrator 3.0.2 GA released: raft consensus, SQLite
Using Active Record migrations beyond SQLite
Related Stack Decisions
MongoDB

I starting using MongoDB because it was much easier to implement in production then hosted SQL, and found that a lot of the limitation you think of from a document store vs a relational database were overcome by connecting the application to a graphql API, making retrieval seamless. Mongos latest upgrades as well as Stitch and Mongo mobile make it a perfect fit especially if your application will be cross platform web and mobile.

See more
Anton Sidelnikov
Anton Sidelnikov
Backend Developer at Beamery · | 1 upvotes · 386 views
MongoDB
PostgreSQL

In my opinion PostgreSQL is totally over MongoDB - not only works with structured data & SQL & strict types, but also has excellent support for unstructured data as separate data type (you can store arbitrary JSONs - and they may be also queryable, depending on one of format's you may choose). Both writes & reads are much faster, then in Mongo. So you can get best on Document NoSQL & SQL in single database..

Formal downside of PostgreSQL is clustering scalability. There's not simple way to build distributed a cluster. However, two points:

1) You will need much more time before you need to actually scale due to PG's efficiency. And if you follow database-per-service pattern, maybe you won't need ever, cause dealing few billion records on single machine is an option for PG.

2) When you need to - you do it in a way you need, including as a part of app's logic (e.g. sharding by key, or PG-based clustering solution with strict model), scalability will be very transparent, much more obvious than Mongo's "cluster just works (but then fails)" replication.

See more
Yarn
Redux.js
React
jQuery
vuex
Vue.js
MongoDB
Redis
PostgreSQL
Sidekiq
Rails
#Font-awesome
#Bulma.io

I'm building a new process management tool. I decided to build with Rails as my backend, using Sidekiq for background jobs. I chose to work with these tools because I've worked with them before and know that they're able to get the job done. They may not be the sexiest tools, but they work and are reliable, which is what I was optimizing for. For data stores, I opted for PostgreSQL and Redis. Because I'm planning on offering dashboards, I wanted a SQL database instead of something like MongoDB that might work early on, but be difficult to use as soon as I want to facilitate aggregate queries.

On the front-end I'm using Vue.js and vuex in combination with #Turbolinks. In effect, I want to render most pages on the server side without key interactions being managed by Vue.js . This is the first project I'm working on where I've explicitly decided not to include jQuery . I have found React and Redux.js more confusing to setup. I appreciate the opinionated approach from the Vue.js community and that things just work together the way that I'd expect. To manage my javascript dependencies, I'm using Yarn .

For CSS frameworks, I'm using #Bulma.io. I really appreciate it's minimal nature and that there are no hard javascript dependencies. And to add a little spice, I'm using #font-awesome.

See more


Interest Over Time