11 ms·
This is a good article, but I feel like using Postgres instead of SQLite on the server side would achieve his goals even better: - No need to link with C code.
by hathawsh 8y ago
This is a good article, but I feel like using Postgres instead of SQLite on the server side would achieve his goals even better:
- No need to link with C code. There's a pure go driver for Postgres.
- You get the 'psql' command to inspect and change the database, even while the web app is running.
- You get a lot more database features.
- You can keep the deployment simple by running Postgres on the web app server until you need to scale up.
- Conversion to a full blown cloud database and horizontal scaling is just a matter of configuration.
I understand the desire to keep the stack as simple as possible, but it looks to me like Postgres would actually be simpler than SQLite for the server side.
- colanderman 8y agoAdded bonus: if you trample memory, you don't corrupt your database. [1] [1] https://www.sqlite.org/howtocorrupt.html#_memory_corruption https://www.sqlite.org/howtocorrupt.html#_memory_corruption
- kodablah 8y ago> You can keep the deployment simple by running Postgres on the web app server until you need to scale up. This doesn't affect deployment. Deployment includes setting up and upgrading and potentially backing up Postgres. All of these are easier with Sqlite. While in general I agree with you, the benefits of putting one file on a server and running it has value over installing an entirely separate software product.
- hn_throwaway_99 8y ago> Deployment includes setting up and upgrading and potentially backing up Postgres. But I find this rather trivial to do with cloud database services like RDS. Why not just use that? At the end of the day it gives you tons of benefits (e.g. easy backups) with no real lock-in because you'd still just be using a normal postgres driver.
- kodablah 8y ago> Why not just use that? No particular reason, depends on the use case. Every choice has tradeoffs, and there are cloud-specific ones that can hinder mobility even if it uses a common tech. Lock in is about more than code reuse especially as dependence grows. Granted, for many use cases it might be the best option, but we shouldn't pretend like it's the exact same mobility profile as copying a DB file.
- qznc 8y agoWhat about local development? With sqlite I can clone my repo, execute something like "make run" and my server runs.
- hn_throwaway_99 8y agoIt's quite simple to do the exact same thing with postgres, you just configure a separate connection string for prod vs local deployments.
- pvg 8y agothe desire to keep the stack as simple as possible It's a somewhat deceptive simplicity, to boot. The fact that you can use SQLite like this is a testament to its versatility and quality but it's not really for this. There's a conceptual overhead in trying to wedge it into this role and it can also easily become a practical one.
- qznc 8y agoCan you deploy Postgres by simply linking it into your executable?
- ngrilly 8y agoNo you can't. But you can deploy the PostgreSQL executable along your app executable, and run it as a "sidecar" process, using a Unix-domain socket to let your app communicate with the PostgreSQL server, and setup PostgreSQL to store the database files in a location specific to your app, instead of a system global location. It's a bit unusual, but it's possible, and PostgreSQL command line makes this relatively easy.
- lmm 8y agoYes, though it's a less common configuration and so a bit fiddly and underdocumented.
- ngrilly 8y agoAs far as I know, there is no way to link PostgreSQL as a library in another executable. At least, nothing supported by the official PostgreSQL project. Even MySQL, which used to be available as an embedded library, got rid of this, feature a long time ago. Do you have any link to this "underdocumented" feature?