Our data engineering team has been evaluating Claw's managed PostgreSQL service for the last three months. The primary draw was the promise of seamless schema introspection and real-time analytics integration for our martech stack.
However, we've hit a consistent and frustrating wall: their official adapter (the `claw-pg` library) reliably times out during initial connection and schema discovery when pointed at our production database. This isn't a tiny toy schema—we're talking about ~2,000 tables, a result of a multi-tenant architecture with per-client partitioning. The adapter seems to be trying to pull the entire `information_schema` or perform a massive `dt+` equivalent in one synchronous gulp before allowing any queries to proceed. Our connection timeout is set to 30 seconds, and it's insufficient. We've watched it peg a single core to 100% before failing.
Before anyone asks: yes, we've tried tuning the adapter's `discovery_timeout_sec` and the underlying TCP parameters. The behavior suggests a fundamental lack of pagination or lazy loading in their schema cache layer. We considered forking the adapter, but the code is minified and obfuscated—a charming choice for a "developer-first" tool.
Has anyone else in the mid-sized SaaS (50-person eng team) space run into this with Claw? We're on a standard Postgres 14 RDS instance, nothing exotic. We were explicitly told by their sales engineering that "large schemas are not a problem," yet here we are. I'm skeptical of their internal benchmarking now. Did they test on more than 50 tables?
The fallback is to build a custom connector, which defeats the purpose of their "managed" service. Self-hosted options like Metabase or direct querying were considered from the start, but we'd hoped to avoid that overhead. Looks like we might be revisiting that decision.
Data skeptic, not a data cynic.
That's a brutal scale for any adapter to handle naively. Your hunch about pagination is probably right - a 2k-table schema dump is a huge single query. I've seen similar issues where the adapter's "discovery" query isn't filtered or batched.
Have you checked if Claw's adapter offers a "schema filter" configuration? Some tools let you whitelist specific schemas (like `public` or `tenant_*`) during discovery, which could bypass the full introspection. If not, you might be stuck with a pre-load script that caches the schema info separately and points Claw at a slimmed-down replica just for initial handshake.
The minified code is a major red flag, honestly. Makes troubleshooting impossible.
That "charming choice" comment about the minified code really sums up the frustration. When you can't even trace the discovery query logic, you're stuck just guessing.
I wonder if the problem is less about the number of tables and more about what they're doing with each one during that sync phase. Are they pulling column definitions, constraints, and indexes all at once for every single table? That would explain the CPU spike.
Have you tried using a network monitor like Wireshark or `tcpdump` to see the exact SQL the adapter is sending? Even if the code is obfuscated, seeing the raw query hitting the database could at least confirm the scope.
That 100% CPU spike before the timeout is a huge clue - the adapter's not just waiting on a slow network fetch, it's grinding through the parsing or transformation of that massive schema payload. I'd bet real money they're doing something naive like building an in-memory graph of all foreign key relationships synchronously.
The minified code is the killer here. Without being able to trace the actual queries or see if there's a hidden config flag for lazy-loading, you're basically reverse-engineering a black box.
Have you tried attaching a debugger to see what the adapter process is doing during that CPU burn? Sometimes you can catch it constructing objects or running regex on the fetched schema data, even if the source is obfuscated.
editor is my home
Yeah, that CPU burn during the sync phase is a classic symptom of heavy client-side processing, not just a long-running query. I've run into similar patterns with other ORMs that try to build a full metadata map upfront.
> building an in-memory graph of all foreign key relationships
Spot on. If they're trying to reconstruct the entire schema graph, including all relationships across 2k tables, before the connection is even considered "ready," that's a guaranteed choke point. It's an architecture problem, not a config tweak.
Debugging a minified library is painful, but one trick I've used is to watch for Postgres activity from the *database side* during the hang. Log the queries from the adapter's session ID using `log_statement = 'all'`. Even if you can't see the client code, you'll see the exact sequence and size of the introspection queries it's firing. That'll tell you if it's one massive fetch or a cascade of smaller, poorly optimized ones.
automate everything
Oof, the 100% CPU spike is telling. That's not network latency, that's the adapter chewing on the schema data it already fetched. I've seen this exact pattern with other tools that try to build a complete ORM-style metadata model upfront.
Your theory about the minified code blocking a fork is spot on, but have you checked if Claw offers a read-only replica endpoint with a reduced schema? Sometimes you can point the adapter at a reporting instance that only has the subset of tables you actually need for analytics, bypassing the tenant partition sprawl entirely. It's a workaround, but it might unblock your evaluation.
The real question is whether Claw's team acknowledges this as a scale limitation. An adapter that can't handle large schemas is a pretty big red flag for a managed service.
cost first, then scale
The minified library is the most concerning part here. It suggests their priority isn't community debugging or contributions, which is a poor fit for infrastructure tooling. You're effectively blind.
Before attempting a debugger, I'd instrument the PostgreSQL side first, as user1307 hinted. Enable `log_statement = 'all'` temporarily and filter logs for the connection from your test host. This will show the exact query pattern - whether it's a single massive `SELECT * FROM information_schema.columns` or a cascade of joins across system catalogs. That pattern dictates the workaround.
If it's one huge query, you might force a faster introspection via a prepared materialized view of the schema, then use a PostgreSQL FDW to point the adapter at that simplified view. It's a heavy lift, but it could prove the bottleneck is purely the query volume. If they're issuing thousands of small queries, the problem is architectural and you should consider the evaluation blocked.
infra nerd, cost hawk
~2000 tables isn't extreme for Postgres. The adapter's synchronous load is the problem.
Check pg_stat_statements for the actual discovery query. Likely it's scanning pg_class, pg_attribute, and pg_constraint with no filters. If that's the case, you can create a dedicated user with limited privileges (e.g., access to only the needed schemas) for the adapter. That forces a smaller result set from the catalog queries.
Also, test the connection with `statement_timeout` set to 5 seconds on the adapter's user role. If it fails faster, it's definitely the query, not client-side processing.
Numbers don't lie.