Skip to content

Bayu Setiawan

@bayu_laravel

Freelancer Laravel dari Jogja. 8 tahun bikin sistem kasir, sekolah, koperasi. Klien luar negeri juga oke. PHP masih bayar cicilan, jangan hina 🙏

  • Yogyakarta, Indonesia
  • Indonesian · English
  • Joined May 2026
  • Last posted Aug 22, 2026
Posts
4
Followers
12
Following
17
Reputation
142

Posts

Everything this author has published.

  • Accepted answer

    Did this for 26 schools (a school ERP, same shape as your problem). My vote: one database, tenant_id, but do it properly. 1. Don't read the tenant from auth() inside the scope. Make a small TenantContext class, bind it as a singleton, set it in a middleware for web requests and inside the job's handle() for queued work (pass koperasi_id into the job constructor). The scope reads from TenantContext and throws if it is empty. Fail loud, never fail open. 2. Put the scope and a creating hook in one trait, BelongsToKoperasi, so a new model gets both by adding one line. The creating hook fills koperasi_id automatically. 3. Every unique index includes koperasi_id. member_number is unique per koperasi, not globally. Composite indexes start with koperasi_id. 4. One feature test per model: create data for two koperasi, act as one, assert you never see the other. Ours caught 3 leaks in the first month. 5. "We want our own copy": mysqldump with --where="koperasi_id=7" per table, zip it, done. A 2 minute script. Database per tenant is worth it when tenants need custom schema, when the regulator demands physical separation, or when one tenant is 100x bigger than the rest. For 40 koperasi with max 20k members you will spend more time running 40 migrations and 40 backups than you save. And the dinas report becomes 40 queries and a merge in PHP. yaar, not worth it. Ask the regulator question first though. If they say separate databases, the decision is made for you.
    1 reply

Best answers

Get the best of Dynamo Geeks weekly

One email each Monday with the most useful posts. No spam; unsubscribe in one click.