One guide per system: the read-only credential BurnLedger will accept, the query placeholder this connector actually substitutes, the transport it requires, and the failure modes that cost real debugging time. Every guide's examples call the real SDK, and every connector here has been certified against the live service.
Two rules hold everywhere: BurnLedger never writes to your systems — no probe writes, no dry runs — and there is no universal query placeholder: using another connector's placeholder is rejected rather than silently matching nothing. Transport requirements are collected in the transport security reference.
How read-only is established depends on the engine, and each guide says which case applies. Eight connectors — PostgreSQL, MySQL, Oracle, SQL Server, Teradata, Redshift, Snowflake, Databricks — read the engine's own privilege tables and refuse a write-capable credential outright. Eight more try that first and fall back to your read_only: true assertion when the backend cannot answer: MongoDB, Elasticsearch, Cassandra, Neo4j, Redis, GCS, S3, DynamoDB. Azure Blob, HBase and MarkLogic expose no privilege introspection at all, so the assertion is the only gate — registration is refused without it, but a write-capable credential supplied with it is accepted. BigQuery reads the dataset ACL: a detected WRITER/OWNER grant is refused like everywhere else, and because that ACL cannot see project-level or group grants, everything short of a positive match falls back to the assertion. Where the assertion is what stands behind the verification record, the credential really has to be read-only; each guide shows how to confirm it yourself.