If you're just starting a startup, go with Postgres for most things. With limited devops resources it'll be good enough in most scenarios.
You can always over optimise later on.
Just use Postgres
81–90 of 238 posts
Re: Just use Postgres
#82Use what you know, ship useful stuff.
I agree.
Mariadb is one of the easiest dbs i have ever used.
Easy to setup and flexible.
I prefer to use whatever makes it quicker to build something, which usually means whatever I am experienced with already.
Building products is what’s important at the end of the day.
No body cares, nor should they, what kind of tools Michael Angelo used. His art is what we value.
Re: Just use Postgres
#83My own advice would be start with SQLite and do a trivial migration to Postgres if warranted.
Re: Just use Postgres
#84I'd like to mention that CouchDB is really useful for one reason - a very robust sync story with clients, and a javascript version called PouchDB that can run on the browser and do bidirectional sync with remote Couch instances.
This can be done with sqlite by jumping through a few extra hoops, and now with in-browser WASM postgres, there as well with a few more hoops, but the Couch -> Pouch story is easy and robust.
Re: Just use Postgres
#85On the MySQL vs Postgres topic: We migrated for two reasons. The first is that I consider everything remotely owned by Oracle as a business risk. Personal opinion and maybe too harsh, but Oracle licenses are made to be violated accidentially so you can be sued and put on the license hook once you're audited, try as you might. But besides that, Postgres gives you more tools to keep your data consistent and the extensi…
Yeah there's absolutely no reason to use MySQL. You should use MariaDB if you are stuck on a MySQL project to avoid Oracle. And you should use PostgreSQL for everything new.
Re: Just use Postgres
#86The "SQLite is just a file" thing is actually an advantage. The example of a website is actually a pretty poor one, since any website that needs to scale beyond a single box has many options. The two easiest ones are: - Mix static and dynamic content generation (and let's face it, most websites are mostly static from a server perspective) - Designate a writer node and use any of the multiple SQLite replication featur…
> The "SQLite is just a file" thing is actually an advantage. It's more like besides the point. Everything in Linux is "just a file".
It can be a process and some unnamed sockets also, which is the main difference between PostgreSQL and SQLite.
Re: Just use Postgres
#87> If you see a college student or fresh grad using MongoDB stop them. They need help. They have been led astray. I like this sentence way more than I should.
This sentence has no substance. It gives the reader nothing to understand why MongoDB has both happy customers some who have been disappointed.
The explanation is in the paragraph before it
Re: Just use Postgres
#88Totally agree - I have tried many databases of all flavors, but I always come back to Postgres. HOWEVER - this blog post is missing a critical point.... the quote should be: ---> Just use Postgres AND ---> Just use SQL "Program the machine" stop using abstractions, ORMs, libraries and layers. Learn how to write SQL - or at least learn how to debug the very good SQL that ChatGPT writes. Please, use all the very powerf…
May I ask question about this part? "Push all your business logic into big long stored procedures/functions - don't be pulling the data back and munging it in some other language - make the database do the work!" From my courses I had at university, I've been led to believe that the current trend is doing hexagonal architecture, as that allows for better modularisation of the project and helps keep code clean over ma…
With Pglite in a few years you'll be able to treat Postgres as a library, and merely allow selecting between in-process and remote via configuration.
The first job of a database is to be a data structure for persisting data, but you're allowed to extend said data structure in your own code. As long as you can come up with a way to keep all the code in version control, test it, etc., it's fine.
Re: Just use Postgres
#89On the MySQL vs Postgres topic: We migrated for two reasons. The first is that I consider everything remotely owned by Oracle as a business risk. Personal opinion and maybe too harsh, but Oracle licenses are made to be violated accidentially so you can be sued and put on the license hook once you're audited, try as you might. But besides that, Postgres gives you more tools to keep your data consistent and the extensi…
MySQL has a very mature open source HA story with the flavors of group replication, as well as being able to replicate DDL. Not to mention Orchestrator and friends.
As a matter of fact, EnterpriseDB (the largest contributor to Postgres) has a paid multi master offering, so there's anti incentives in place to improve its HA story...
Re: Just use Postgres
#90I'm always cautious with a one-size-fits-all approach. If a team is working on a small project and SQLite works then great. You can use a SQLite database on something like a $4/month DigitalOcean droplet. Can't say the same for Postgres.
> AI is a bubble
Many say this but Generative AI and LLMs have gotten bunched up with everything else. There is a clear need for vectors and multimodal search. There is no core SQL statement to find concepts within an image for example. Machine learning models support that with arrays of numbers (i.e. vectors). pgvector adds vector storage and similarity search for Postgres. There was a recent post about storing vectors in SQLite (https://github.com/asg017/sqlite-vec).
> Even if your business is another AI grift, you probably only need to import openai.
There's much more than this. There are frameworks such as LangChain, LlamaIndex and txtai (disclaimer I'm the primary author of https://github.com/neuml/txtai) that handle generating embeddings locally or with APIs and storing them in databases such as Postgres.