[999900000999]

Depends.

If you want to fully embrace the vibe tables are difficult.

Even before LLMs, I was at a certain company that preferred MongoDB so we didn’t need migrations.

Sometimes you don’t care about data structure and you just want to toss something up there and worry about it later.

Postgres is the best answer if you have a solid team and you know what you’re doing.

If you want to ride solo and get something done fast, Firebase and its NoSQL cousins might be easier .

[pojzon]

I really enjoy this comment.

> Postgres is the best answer if you have a solid team and you know what you’re doing.

Not every type of data simply fits into relational model.

Example: time series data.

So depending on your model - pick your poison.

But for relational models, there is hardly anything better than postgres now.

It makes me happy coz I always rooted for the project from earily 2000s.

[freilanzer]

Even for timeseries there is https://github.com/timescale/timescaledb. Haven't used it, just knew it existed.

[abraxas]

It's very good. Postgres by itself can handle a very high volume of inserts (I did over 100,000 rows/s on very modest hardware). But timescale makes it easier to deal with that data. It's not strictly necessary but it's very time series friendly (good compression, good indexing and partitioning etc). Nothing a pg expert can't accomplish with a vanilla postgres but very, very handy.

[mplanchard]

I haven’t tried timescale, but I have found postgres with time-based partitions works very well for timeseries data. Unless you’ve got really heavy indexes, the insert speed is phenomenal, like you said, and you’ve got the freedom to split your partitions up into whatever size buckets makes the most sense for your ingestion and query patterns.

A really nice pattern has been to use change data capture and kafka to ship data off to clickhouse for long-term storage and analytics, which allows us to simply drop old partitions in postgres after some time.

[abraxas]

I think timescale will compress them heavily on your schedule so if that's acceptable to your use case you might be able to do away with clickhouse. Hard to say of course, without knowing details around your insertion and query patterns, retention requirements and aggregations you need. But timescale can do a lot of that with pretty straightforward syntax.

[argulane]

I have used TimescaleDB in my last work place. We needed a easy way to store and visualize 500hz sensor data for few 10s of devices. We used it and Grafana to build a internal R&D tool and it worked way better than I imagined. Before I left I think the DB was using ~200GB on a compressed btrfs volume in DigitalOcean droplet and still performed fine for interactive Grafana usage.

[999900000999]

Don't get me wrong, Postgres is awesome when things work.

But, for example I was working on a .net project and entity framework decided it couldn't migrate Postgres tables correctly.

I'm not a SQL person, at this point my options are to drop tables, and let .net recreate them or try and write my own migrations.

This just isn't an issue with Firebase. I can add all the fields I want directly on the client.

[SchemaLoad]

What situations do you encounter where you don't care about the structure of the data? The only ones I've ever encountered have been logging, where it's only purpose is to be manually text searchable, and something like OpenStreetMap where everything is just a key value store and the structure is loosely community defined.

As soon as you have a loosely defined object you can't access any specific keys which makes it useless for 99% of times you want to store and retrieve data.

[999900000999]

You define the data schema client side.

That's the entire idea behind Firebase. It makes prototyping much faster. I don't know how well it scales, but it works for most smaller projects.

[graealex]

Wait until you hear about ORMs.

[999900000999]

I still have to create tables. I still have to migrate tables, these are all things I don't need to worry about with firebase.

It all depends on what you need to actually do. The only real weakness of Firebase is the Google lock in.

[SchemaLoad]

You still have to worry about data migrations without a schema though. Unless you just never access old records.

[999900000999]

Depends.

Let's say you have an object called box.

It has 3 properties, the id, it's name and it's weight.

4 months later you add a 4th property. Cost, odd records that don't have a cost just return null for that field.