Hacker News

At my current job I'm in charge of developing our data analytics platform, and with it being so data-driven I was able to implement like 95% of the logic directly into the database largely as functions and stored procedures. The remaining 5% of the application code is mostly Python, which merely acts as a connector from an HTTP gateway to call said functions and render their output as XLSX files. It's amazing how much I was able to do with mostly SQL (I still had to break down and use plpgsql at times to handle the more procedural stuff, but that was the exception).

And now I'm in the process of replacing some of the more intensive data analytical stuff with DuckDB, which has been just an awesome experience.

Long live SQL!

There are very few things I would want to do less than complicated logic in SQL. At least these days we get the alternative of SpacetimeDB functions https://spacetimedb.com/docs/functions But having everything in stringly typed environment with minimal stdlib in things like mssql? Yeah, there's a reason why it's not a popular pattern.

Its always a very interesting architectural question when deciding at what level(s) the business logic should live. There absolutely are valid reasons for some to go in SQL, though I tend to avoid putting the most complex logic there when its really tricky.

When it really gets hairy, or when the business logic keeps changing under my feet, I'll try to find constraints I can put in the db as a final backstop while leaving most of the logic somewhere in the application stack.

I can count on one hand the number of people I've worked with that really know SQL well enough to pick up complex business logic at that layer and work with it easily. I've been mainly in small companies for the last decade, I'm sure at larger orgs there are more data engineers running around that could own it.

I hated debugging and fixing stored procedures for legacy 2000s apps in de 2010s. The SP code wasn't treated like regular code, it wasn't source controlled. Mostly bad memories from having business logic inside the DB instead of having it all inside the code.

We do this as well. There are some downsides of course, but overall it has worked out well for years. Funny we were told the use of stored procedures is a problem and the reason the product should be retired. You should see the dependency graph of the replacement.

> we replicated the prod DB every morning

You may be storing logic in your database, but most businesses store data in their databases, and the amount of data they store (mostly because they can't tell what's important and what's not) makes copy-pasting their database every morning pretty unrealistic.

True. The kind of guarantees you can get when staying within the database can often solve whole categories of problems. But, DX of having non-trivial logic inside Postgres is not great either: I feel that I'm making a significant trade-off. I've also seen interesting languages that compile to SQL, would consider those in some cases.

Yes, this is fantastic! I'm trying it right now. I look forward to the day when LLM inferencing can be done in a sql query and take less than the age of the earth to do something. This works way better than I would have expected, since, well, it's sql all the way down.

I noticed the cedardb.com blogpost on the project is slashdotted at the moment, but the game itself plays just fine.

These are great.

There is a whole chapter in Designing Data Intensive Applications dedicated specifically to handling atomic transaction concurrency issues while avoiding the performance trade-off you're describing here, you will definitely find it interesting.

https://www.oreilly.com/library/view/designing-data-intensiv...

It's not you, it's WordPress.

My go to comparison is going to a grocery store, asking for tomatoes, and the clerk needs to first pull them out of some shelf under the counter

Man hackernews really took a deep dive.

Makes me wonder how good a better relational language than SQL might be for general programming.

I was actually just recently looking if there is a self-hostable alternative to a HTAP system like TiDB + TiFlash with a Postgres-compatible syntax, but LLMs didn't really pick up on CedarDB yet. These guys know game.

This but without the /s