Timescale Cloud
You set up timescale cloud by creating a service and assigning Postgres database roles. You then restrict network traffic and hand out separate read and write keys. Most engineering teams start by sharing one default admin user across their apps. That broad role lets any person or script alter tables or read private rows. How timescale cloud manages database roles and permissions The platform runs on top of standard Postgres role rules and network controls. When you create a new database serv
Cloud: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up timescale cloud by creating a service and assigning Postgres database roles. You then restrict network traffic and hand out separate read and write keys. Most engineering teams start by sharing one default admin user across their apps. That broad role lets any person or script alter tables or read private rows.
How timescale cloud manages database roles and permissions
The platform runs on top of standard Postgres role rules and network controls. When you create a new database service, the system sets up an admin role. Teams must log in with this account to build custom roles for their apps. You should create one role for writing data and another role for reading it.
Data ingest scripts only need permission to add new rows to time-series tables. Analytics tools and staff only need permission to read from specific views or tables. You can also set up network allowlists to block traffic from unknown IP addresses. For deeper security, teams link their cloud network to the database using private links. This ensures traffic stays off the public internet while apps send or read data.
What native database roles solve and what they miss
Native database roles and network rules do a good job of blocking outside attackers. They decide who can log in and which tables a role can touch. This setup stops a basic read-only reporting tool from dropping a core table. It also keeps public web traffic away from your database port.
Still, static roles do not inspect what individual queries do after a user logs in. Once an engineer connects with a valid role, every query runs with full role permissions. If a table holds user emails or phone numbers, a basic query returns them all. Masking rules that rewrite matched fields in results are not part of standard role setups. Static passwords also sit in local files, where staff can copy or share them. Database logs show which role ran a query, not which human actually typed it.
Cloud: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Why shared time-series credentials create audit gaps
Time-series workloads often mix system metrics with user event data in the same database. Developers need to check this data when they fix bugs during a live outage. To move fast, teams often share one fixing role among all on-call engineers. Everyone logs in with the same username and password from their own laptops.
When someone runs a slow query or pulls sensitive card numbers, the trail goes cold. The database log only records the shared role name, not the person behind it. Rotating that shared password breaks local setups for the whole team at once. Because rotation hurts daily work, teams leave the same password active for many months. You need a way to tie every single query to a real team member.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How should we separate roles for apps and humans in a time-series database?
Create dedicated write-only roles for ingest apps and strict read-only roles for human staff. Never let human users log in with the same credentials used by background scripts.
Can native Postgres roles hide sensitive columns like emails or phone numbers?
You can restrict column permissions or build custom views, but maintenance takes heavy effort. Standard roles do not rewrite matched fields in query results on the fly.
What happens when an engineer leaves the team if we use static passwords?
You must rotate every shared password they knew and update all affected apps and scripts. Tying database sessions to your central identity provider stops access the moment they leave.