Hello, I’m Alexandru Șerban, and I’m building Scalple. Happy to go deep on any part of it.
The problem we kept running into:
Across startups and even some mid-sized companies we saw the same three ways of handling production database access:
1. a shared .env in 1Password
2. an SSH tunnel through a bastion
3. just giving engineers the database password
All three break down the same way: when something goes wrong, you don’t know who ran which query, on what data, or when.
That works until it doesn’t. A GDPR data subject request comes in. An auditor asks for access logs. Enterprise procurement wants proof of controlled production access. You go digging and realize there’s nothing solid—just Slack messages and guesswork.
What we built:
Instead of handing out connection strings, Scalple gives engineers a full database client and a script editor. They write a function, and it runs server side inside a V8 isolate—with a 1 MB memory cap, a 500 ms execution limit, and no outbound network access.
Database credentials never leave control plane. Engineers get the query results—nothing more.
Every operation is written to an append only audit log. There’s no UPDATE or DELETE path in the schema—even for us as admins. Each entry hashes the previous one, creating a verifiable chain. You can export the entire log as a signed, timestamped PDF for compliance and audits.
What it’s not:
Tools like Teleport or Boundary control whether a connection can be established. Scalple operates at a different layer—it controls what happens after the connection: the queries themselves, which fields are returned, and the conditions applied at the record level.
* the tradeoffs of using a V8 isolate sandbox
* the append only schema design
* and whether using TypeScript as a query language would work for your team
S3RBVN•1h ago
The problem we kept running into:
Across startups and even some mid-sized companies we saw the same three ways of handling production database access:
1. a shared .env in 1Password 2. an SSH tunnel through a bastion 3. just giving engineers the database password
All three break down the same way: when something goes wrong, you don’t know who ran which query, on what data, or when.
That works until it doesn’t. A GDPR data subject request comes in. An auditor asks for access logs. Enterprise procurement wants proof of controlled production access. You go digging and realize there’s nothing solid—just Slack messages and guesswork.
What we built:
Instead of handing out connection strings, Scalple gives engineers a full database client and a script editor. They write a function, and it runs server side inside a V8 isolate—with a 1 MB memory cap, a 500 ms execution limit, and no outbound network access.
Database credentials never leave control plane. Engineers get the query results—nothing more.
Every operation is written to an append only audit log. There’s no UPDATE or DELETE path in the schema—even for us as admins. Each entry hashes the previous one, creating a verifiable chain. You can export the entire log as a signed, timestamped PDF for compliance and audits.
What it’s not:
Tools like Teleport or Boundary control whether a connection can be established. Scalple operates at a different layer—it controls what happens after the connection: the queries themselves, which fields are returned, and the conditions applied at the record level.
There’s a free self hosted tier (no credit card required): https://scalple.com/install
I’d genuinely love your take on a few things:
* the tradeoffs of using a V8 isolate sandbox * the append only schema design * and whether using TypeScript as a query language would work for your team