Intended audience: developers administrators
AO Platform: 4.5
Security, Performance & Operations
Performance and Latency
-
Concurrent users supported per pod: 12-15
-
P95 response time for critical operations:
-
DB latency + LLM latency + 300 ms (typical absolute response times vary from 6 secs to 60 secs, depending on question complexity)
-
Caching
-
Browser: Apply cache-control headers for static resources (CSS, JS, images).
-
Server-side: Use Redis for frequently accessed data such as reference tables, configuration, and session tokens if needed. Define TTLs and explicit invalidation for cached entries to maintain data correctness.
-
LLM: Intent determination/semantic SQL caching
Data Access and Authorization
Role-Based Access Control (RBAC)
-
AO Platform implements configurable RBAC with system roles such as:
-
System Admin
-
Standard User
-
Custom Role (as needed)
-
-
ACLs are defined centrally and enforced at both API layer (authorizing requests) and UI layer (controlling visibility and actions).
Attribute-Based Access Control (ABAC)
ABAC is implemented within the semantic layer using managed semantic objects (MSO) and their properties
-
Authorization policies are evaluated at the MSO or MSO property level, allowing entity, column-level / attribute-level control.
-
Access to MSOs and their individual properties is restricted based on RBAC roles.
Least Privilege & Governance
-
All roles and permissions follow the principle of least privilege.
-
Elevated roles (Admins) must be granted via approved processes and reviewed at least quarterly.
Data Security
Encryption In-Transit
-
All traffic between browsers and load balancer uses HTTPS/TLS 1.2.
-
External integrations (Snowflake etc.) must use secured channels (HTTPS, TLS-secured JDBC/ODBC).
Encryption At-Rest
-
RDS: Encrypted using AWS-managed or customer-managed KMS keys (AES-256).
-
S3: Server-side encryption enabled for buckets storing customer data.
-
Snapshots & Backups: RDS snapshots and S3 backups are also encrypted.
Data Masking
-
Data masking in UI is a custom extension currently. It is a roadmap item to make it configurable.
Logging & Audit
-
Record all access to sensitive resources with User identity, timestamp, and source IP Address.
-
Audit logs are stored in an immutable or tamper-evident way (i.e., CloudWatch Logs with restricted access) and retained for at least 12–24 months or as per customer preference.
Observability
Logging
-
Application logs include errors, warnings, and security events.
-
Logs are centralized and stored in CloudWatch
-
Structured (JSON) for search and analysis.
-
Metrics & Monitoring
We use CloudWatch, DataDog, and Prometheus to monitor the instances hosted in our cloud:
-
Infrastructure (EKS, nodes): CPU, memory, disk, network.
-
Application: RPS, latency percentiles (P50, P90, P95, P99), error rates.
-
RDS: CPU, connections, free storage, read/write latency, slow queries.
Alerts
-
DataDog alerts are configured for:
-
Resource saturation on EKS nodes (CPU/memory > threshold)
-
RDS issues (high CPU).
-
How is role-based access control managed across data sources, analytics layers, and AI features?
The platform has a robust and elaborate RBAC. It can be configured to restrict or provide access at an MSO, table, or column level. Additionally, you can also apply custom filters (for eg, the Sales West role can access only rows with region = ‘West’) to restrict row visibility.
What are your performance benchmarks for high-query volumes, large-scale deployments, or real-time analytics?
We have scaled the platform to billions of rows. Since the entire platform is containerized, it can scale for high-volume queries across large datasets. Queries are pushed down to underlying data platforms – our performance is a function of the underlying data platform’s performance.
Go to all FAQs.
Contact App Orchid | Disclaimer