Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Nice, thank you for the insight.

I can tell that the on-premises will be deployed on AWS accounts. We can manage the resources ourselves.

We have few fanouts that can be refactored. So Redis/Valkey for SQS is OK, hopefully it can also cover our SNS use case.

I am afraid Kubernetes is overkill for our lambda needs.

If we manage to bundle our whole app in one server and have only 1-2 clients on -premise, do you still suggest Kubernetes or a simpler rsync on all servers is enough?

Also, should we have a separate database instance for each client, or a Postgres cluster sharded? The latter seams more manageable.



> If we manage to bundle our whole app in one server and have only 1-2 clients on -premise, do you still suggest Kubernetes or a simpler rsync on all servers is enough?

rsync is nice and simple. Personally I'd say at least use Ansible, with its built-in rsync support. Then you can do more than just copy files.

> Also, should we have a separate database instance for each client, or a Postgres cluster sharded? The latter seams more manageable.

Depends on the size. Run postgres separately for your on-prem clients. For your cloud clients, I'd say keep them on the same server until you start to get over 100GB-1TB of data, then start to think about sharding. RDS gets super expensive, so sharing too early may be uneconomical.

> I am afraid Kubernetes is overkill for our lambda needs.

For just Lambda, I agree. But if running everything outside of AWS (i.e. racking servers) then it shines, because then you have your app, postgres, valkey, etc, all balanced between servers.


Thank you again, this is gold. We'll do a POC with 1-2 services and see how it goes.


You're welcome! Always happy to give advice. Let's have a call next time. I'm adam@ (company domain in bio)




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: