4 ms·

Consider the source: Heroku needs an alternative to Postgres to be a true competitor to AppEngine. There's something that never gets brought up in these NoSQL

by blasdel 17y ago

Consider the source: Heroku needs an alternative to Postgres to be a true competitor to AppEngine. There's something that never gets brought up in these NoSQL discussions: SQL Databases don't scale down. They aren't very good in multitenant situations where you have a lot of random small-fry users -- you end up just sharding the users across a bunch of different master-slave pairs, and hope that they don't step on each other's toes. Because they take up real resources even if not being used, it's difficult to pull off a freemium model.

silentbicycle 17y ago
SQLite scales down fine, FWIW. It's just not appropriate past a certain amount of concurrent writes, but it's great for prototyping and smaller services.
- blasdel 17y ago
  That is a clever idea I'd not thought of, but it isn't really multitenant -- it just pushes the problem down into the filesystem. It also requires a discontinuous transition to a different SQL database once you graduate from being a small-fry, and from there you're in the same boat as everyone else trying to scale that to multiple machines without application changes.
  - silentbicycle 17y ago
    I'm not sure what you mean by, "it just pushes the problem down into the filesystem". Could you explain? On the upside, SQLite will take disk space, memory, and CPU proportional to actual usage, and compared to (say) Ruby or Python, it's a drop in the bucket. As to the discontinuous transition between it and a bigger system, sure. It's a trade-off. So is worrying about scalability plans during early prototyping, though.
    - blasdel 17y ago
      If you're building a multitenant distributed system like GAE, the SQLite blob needs to be stored in a distributed system too, even if you don't need to handle concurrent access.
      - silentbicycle 17y ago
        Got it. SQLite also explicitly notes that its locking does not work properly with many broken implementations of NFS (http://sqlite.org/faq.html#q5 http://sqlite.org/faq.html#q5), so that's not an option.

by blasdel 17y ago

silentbicycle 17y ago

SQLite scales down fine, FWIW. It's just not appropriate past a certain amount of concurrent writes, but it's great for prototyping and smaller services.

blasdel 17y ago
That is a clever idea I'd not thought of, but it isn't really multitenant -- it just pushes the problem down into the filesystem. It also requires a discontinuous transition to a different SQL database once you graduate from being a small-fry, and from there you're in the same boat as everyone else trying to scale that to multiple machines without application changes.
- silentbicycle 17y ago
  I'm not sure what you mean by, "it just pushes the problem down into the filesystem". Could you explain? On the upside, SQLite will take disk space, memory, and CPU proportional to actual usage, and compared to (say) Ruby or Python, it's a drop in the bucket. As to the discontinuous transition between it and a bigger system, sure. It's a trade-off. So is worrying about scalability plans during early prototyping, though.
  - blasdel 17y ago
    If you're building a multitenant distributed system like GAE, the SQLite blob needs to be stored in a distributed system too, even if you don't need to handle concurrent access.
    - silentbicycle 17y ago
      Got it. SQLite also explicitly notes that its locking does not work properly with many broken implementations of NFS (http://sqlite.org/faq.html#q5 http://sqlite.org/faq.html#q5), so that's not an option.