401–410 of 539 posts
Earlier quoted context omitted.
Hmm backups seems like an important one.
Yes, and is super easy. I do like this: cron to run the backup and then rsync to https://www.rsync.net , then an after script that check it was run and post to my telegram the analysis. That is.
Earlier quoted context omitted.
The author says he wants funding to grow the businesses. Presumably he wants funding and the help from investors to enable quicker growth than what is possible organically.
Yes, "presumably." That's exactly the problem..
He does not say what kind of funding he has been trying to get, but if my presumption is right, then some kind of Y-Combinator style hypergrowth.
I think the response he got is sensible if he was approaching "Excel investors" who are risk averse, not targeting hypergrowth.
Earlier quoted context omitted.
Because it doesn't make a difference, because `SELECT 1` doesn't need to touch the database: Running 100,000 `SELECT 1` queries: PostgreSQL (localhost): 2.71 seconds SQLite (in-memory): 0.07 seconds SQLite (tempfile): 0.07 seconds ( https://gist.github.com/leifkb/d8778422d450d9a3f103ed43258cc... )
How about pg on Unix socket?
Running 100,000 `SELECT 1` queries:
PostgreSQL (localhost): 2.84 seconds
PostgreSQL (Unix socket): 1.93 seconds
SQLite (in-memory): 0.07 seconds
SQLite (tempfile): 0.06 seconds
> The enterprise mindset dictates that you need an out-of-process database server. But the truth is, a local SQLite file communicating over the C-interface or memory is orders of magnitude faster than making a TCP network hop to a remote Postgres server. I don't want to diss SQLite because it is awesome and more than adequate for many/most web apps but you can connect to Postgres (or any DB really) on localhost over…
More features is a net negative if you don't need those features. Ideally you want your DB to support exactly what you need and nothing more. Not typically realistic but the closer you can get the better.
Earlier quoted context omitted.
> Sqlite smokes postgres on the same machine even with domain sockets [1] for inserts only into singe table with no indexes. Also, I didn't get why sqlite was allowed to do batching and pgsql was not.
> for inserts only into singe table with Actually, there are no inserts in this example each transaction in 2 updates with a logical transaction that can be rolled back (savepoint). So in raw terms you are talking 200k updates per second and 600k reads per second (as there's a 75%/25% read/write mix in that example). Also worth keeping in mind updates are slower than inserts. > no indexes. The tables have an index on…
> - [1] An interactive transaction is a transaction where you intermingle database queries and application logic (running on the application).
could you give specific example why do you think SQlite can do batching and PG not?
Earlier quoted context omitted.
100% true. I ran a top 10 most visited Spanish language site on a Pentium III server. I have the technical chops to do all the articles says. But 10k MRR sounds to me like travelling to Mars. I have 0 ideas and 0 initiative to push them ahead.
Yeah, 25 years in the industry, zero business ideas right here. I can build whatever, I just have zero clue whatsoever what to build. Never have.
It seems to me that I am getting much more good ideas than I can carry on.
Earlier quoted context omitted.
When I was a consultant we would plan out 25 piece cloud deployments for little pie in the sky apps that would never see more than 200 users. Everyone has been trained that 'cloud' means a lot of expensive moving parts and doesn't stop to plan their deployments beyond that.
Digital ocean has Kubernetes ffs. It's all of five minutes to write a deployment yaml and ingress and have literally anything on the web for a handful of dollars a month. I've written rust services doing 5k QPS on DO's cheapest kube setup. It's not rocket science. Serverless node buns with vite reacts are more complicated than this. Ten lines of static, repeatable, versioned yaml config vs a web based click by click…
Neither is "apt install caddy".
Earlier quoted context omitted.
And now big tech often doesn't even have the high availability to show for all that complexity.
Remember if you ever feel disappointed, the king of scale Google playstore updates stats once a day