Data services and observability

Self-service does not choose for you

Nais exposes multiple persistence capabilities because data problems differ. A declaration or Console action can provision infrastructure and credentials; it cannot decide the correct consistency model, privacy basis, retention, schema or recovery strategy.

Availability varies between environments. The current persistence overview is the authoritative comparison.

Data responsibility remains with the team

Nais provisions and maintains infrastructure and integrations according to the team’s specification. The underlying storage may be operated by Google, Aiven or another infrastructure provider. The product team remains responsible for the data and its lawful, secure use.

Before provisioning, answer:

1. What is the data’s purpose and classification?
2. Where may it be processed and stored?
3. Who may access it, and how is that reviewed?
4. How long is it retained, and how is deletion verified?
5. What are RPO and RTO?
6. Which backup or durability feature exists, and does it protect against accidental deletion?
7. Has restore been tested at the application level?
8. Who owns schema, migration, cost and incidents?

“Highly available” and “backed up” are not synonyms. The Nais storage comparison explicitly notes that some durable services do not provide a separate backup against mistaken deletion. Read data responsibilities.

Relational data

For Cloud SQL, plan connection pooling and maximum application scale together. Rolling deployments temporarily add replicas, and each may open a pool. Database saturation can occur while CPU looks healthy.

Use backward-compatible schema changes across rolling versions: expand first, migrate, then contract later. Treat major-version upgrades and instance changes as product changes with testing, observability and rollback/recovery plans. Platform automation does not know whether a migration preserves domain meaning.

Kafka and event ownership

Nais offers Kafka as a managed service through Aiven. Topics have partitioning and access controls; clients still determine keys, producer acknowledgement, consumer groups, offset commits and error behavior.

Consumers should handle redelivery and be idempotent at the business boundary. Define schema compatibility, ownership and replay before production. Kafka’s durability is not a reason to make it the only master of business data accidentally; the Nais documentation recommends being able to restore the data from another system.

Observability: ask questions with signals

Nais standardizes the three main signal types:

• logs written to stdout/stderr are collected; structured logs are easier to search and aggregate;
• metrics follow OpenMetrics/Prometheus conventions and are queried/visualized in Grafana;
• traces use OpenTelemetry and are stored in Tempo, with Nais APM providing service and RED views;
• alerts can be evaluated from metrics or logs and routed through supported channels.

Automatic OpenTelemetry instrumentation can create useful baseline telemetry without code changes. It does not know the important business events, correct correlation identifiers or what “good service” means to users.

Use each signal deliberately:

Never place tokens, secrets or unnecessary personal data in logs, span attributes or metric labels. High-cardinality identifiers can make metrics expensive and ineffective; put request-specific identifiers in logs/traces.

Alert on conditions people can act on

An alert needs:

• a user or system impact worth interrupting someone for;
• a threshold and duration that avoid transient noise;
• an owner and delivery route;
• context, dashboard and runbook;
• a safe first action and escalation path;
• periodic review of whether it was useful.

Start with availability, latency and correctness SLOs. Resource alerts such as memory pressure are useful when they predict user impact or imminent failure. Avoid paging on every pod restart; Kubernetes restarts are normal, while a restart loop and loss of healthy capacity are not.

Study the current Nais observability overview and observability tutorial.

Architecture checkpoint

An application stores case state in Cloud SQL, publishes case events to Kafka, indexes searchable text in OpenSearch and emits every case number as a Prometheus label.

The architecture needs an authoritative-source statement, transaction/event consistency, replay and reindex strategy, data classification in every copy, recovery testing, and ownership. Case number must not be a high-cardinality metric label; use bounded metrics for trends and safe correlation in logs/traces for individual cases.

Official study links

• Persistent data overview
• Data responsibilities
• Kafka
• Observability
• Automatic instrumentation

Google Cloud bridge

Cloud SQL, Cloud Storage and BigQuery retain their Google Cloud behavior when provisioned through Nais. The Google Cloud data and operations module explains the underlying service trade-offs and Well-Architected view.