The data platform 1Password needed didn't exist. So we built it.

Consider a few tasks that take place across every business, every day: A product team ships a feature and wants to know if customers are using it successfully. A finance team needs customer and account information for planning. An analyst needs definitions to create a report. An AI assistant needs operational context to answer a business question. Those sound like different workflows, but they all rely on the same underlying data. And each one of these actors, across each of these teams, needs that data to be both accessible and trustworthy. At 1Password, trust is at the center of everything we build. Millions of people and businesses rely on us to protect the credentials, secrets, and access workflows that power modern work. The same principle applies to our own internal data. As our products, systems, and use of AI evolved, data became a shared dependency across the business. It powers everything from Unified Access andsecure agentic access patterns for customers, to the workflows used by product, finance, and engineering teams. As those systems grew, so did the number of people and applications that depended on our internal data. But our data infrastructure did not respond well to this. We had built a centralized data lake supported by a growing collection of bespoke data pipelines and one-off solutions. Each new use case required another integration or transformation. Over time, the data platform became a bottleneck: teams turned to CSVs to move faster, and data engineers spent more time maintaining pipelines than enabling new capabilities. What we learned was that manually moving data was no longer enough. Data needs to be available in real time, accessible wherever it’s needed, and trusted through the forms our customers need, whether that is through SQL, APIs, dashboards or AI workflows. Privacy and governance need to be built into data the moment it’s created so every downstream use remains secure and unambiguous by design. This is the foundation we’re building. The problem: Data was available, but storage was tightly coupled with governance and compute The issue was not that we lacked data. We had plenty of it. The problem was that storage, governance, and compute had become tightly coupled inside individual tools. Different systems stored their own copies of the data. Governance rules varied between tools, schema changes could break downstream models, and the teams producing data could not inspect or validate their own raw event streams. That fragmentation also made trust harder to maintain consistently. Every new workflow introduced another ingestion path, another policy surface, or another duplicate copy of the data. It also increased cost and operational complexity as the number of workflows and consumers grew. AI systems amplified those problems because agents depend on machine-readable trust, consistent semantics, and governed operational context in ways traditional dashboards do not. Humans are adept at navigating this kind of ambiguity, but agents need more clarity. So we changed the model. We standardized a shared open data foundation that multiple execution engines and access patterns could operate against consistently. The lesson: Own the data foundation, then build faster on top of it We built the platform around Apache Iceberg tables, an open table format for managing large analytical datasets, giving us a shared open storage layer owned by 1Password rather than any individual compute platform. In this model, compute engines operate against the same underlying data instead of maintaining isolated copies. This separation gives us flexibility without bifurcation. It enables us to make the best architectural choices and select purpose-built platforms for the workloads they are best suited for. That is the thesis behind our adoption of both Snowflake and Databricks. This model allows us to take advantage of their unique strengths without fragmenting the platform itself. Databricks is our engineering and execution plane, handling raw ingestion, distributed processing, and schema registration. Snowflake is our governed consumption plane, where data becomes business and AI ready. Federated governance ensures ownership, lineage, classification, and access controls remain consistent across both platforms. Ownership, governance, and metadata are managed where data is authored, while Iceberg provides a shared foundation across both platforms. The important shift is that no individual platform becomes the system of record; the foundation itself does.That lets us evolve our tooling and workflows without continuous rebuilding and managing the data layers underneath. From raw event to trusted data product Our data lifecycle starts with the team that creates the data. A team implements an event as part of feature delivery or within an external system. Instead of filing a request for a downstream extraction later, the data producer defines the event schema using Protobuf and registers it

Excerpt shown under the publisher's RSS terms · 118 words · full text and figures are on the publisher's site