Dpa Facility
You set up a dpa facility by linking your monitoring tool to target databases. A dpa facility stands for database performance analyzer system, which tracks slow queries and wait times. Most teams start this setup by creating a dedicated monitoring user in each database. They often grant broad read roles so the tool can read system tables and memory stats. When these roles are too wide, the monitoring account or its users can read private rows. How a dpa facility works in your stack A dpa faci
Facility: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a dpa facility by linking your monitoring tool to target databases. A dpa facility stands for database performance analyzer system, which tracks slow queries and wait times. Most teams start this setup by creating a dedicated monitoring user in each database. They often grant broad read roles so the tool can read system tables and memory stats. When these roles are too wide, the monitoring account or its users can read private rows.
How a dpa facility works in your stack
A dpa facility runs on its own server and polls your databases on a timer. It needs a dedicated database account to log in and read system views. Admins create this account and attach roles that allow reading wait states and active plans. The central server stores these stats in its own repo database for charts and alerts. Engineers then log in to the web dashboard to check slow SQL statements and locks.
Setting up the repo database is the first real step for the platform team. You pick a host, assign storage, and give the collector engine write permissions there. Next, you register each production database by entering its host name, port, and login key. The collector tests the login and begins pulling wait data every second without extra agents. Teams also link the dashboard to their directory service so staff can log in with group roles.
Where native permissions fall short
Native roles in the database and the analyzer dashboard decide who can log in. They also control which screens a user can open inside the performance dashboard. Still, static roles do not check what happens when engineers go to fix a slow query. Once an engineer sees a bad query in the chart, they open a database client. They log in to the live database to run explain plans or update indexes.
At that point, native database roles only check if the user has table access. They do not inspect individual commands in flight or block risky updates before they run. Also, query logs and live query results often include raw emails, phone numbers, or card numbers. Standard database permissions let any user with table read rights return those fields in full. Masking tools that rewrite matched fields in results help close this gap during live work.
Facility: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Managing live database sessions safely
To keep live data safe, teams need controls that work at the query level. You should separate the read account used for charts from accounts used by human engineers. Give the collector engine access only to system views, never to customer data tables. When engineers need to run a fix, require peer review on the exact SQL command. Also, make sure your setup rewrites sensitive fields like national IDs in query results.
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
What does a dpa facility do for database teams?
It tracks database wait times, finds slow queries, and shows where resource locks happen. Teams use it to spot bottlenecks and tune SQL code.
Does the collector account need admin rights on target databases?
No, you should only grant permissions to read system views and performance counters. Avoid giving it full admin rights or read access to user tables.
How can teams protect private data during query tuning?
Teams restrict direct table reads and use controls that inspect commands in flight. Applying rules that rewrite emails and card numbers in results also protects live data.