Hyy fauzifadhi,

i can see from your error logs that TigerBeetle is unable to access io_uring syscalls due to seccomp security restrictions.

unfortunately, TigerBeetle requires --security-opt seccomp=unconfined to run in containerized environments, and Railway doesn't currently support custom security_opt configurations

i suggest you to consider using alternative databases If you're flexible ofc, databases like PostgreSQL, CockroachDB, or other options work great on Railway and might meet your needs. or check with TigerBeetle, reach out to the TigerBeetle team to see if they have any workarounds or alternative configurations for restricted environments

you can find some help here : https://github.com/tigerbeetle/tigerbeetle/issues/2446

i hope this helps you!

Hey! TigerBeetle needs --security-opt seccomp=unconfined to run but Railway doesn’t allow custom security options in containers

Options

Use an alternative DB supported on Railway like Postgres or CockroachDB
Contact the TigerBeetle team to see if they have a workaround for restricted environments: GitHub Issue #2446

This is the only practical solution on Railway right now

Right now iam using Postgres as my general database, but i want to use TigerBeetle as secondary database to manage my accounting process. because if only Postgres i need to use locking.

given the seccomp limitation we discussed, here are some approaches to handle your accounting needs while staying on Railway: you can use postgres with better transaction design since you already have Postgres on Railway, you could optimize your accounting logic:

• use serializable transaction isolation levels

• implement optimistic locking instead of pessimistic locking

• use Postgres advisory locks for specific accounting operations

• consider using SELECT FOR UPDATE SKIP LOCKED for queue-like accounting tasks

i reach out also to railway support to express interest in seccomp configuration support. If there's enough demand, can u consider adding this capability in the future, thank you.