Software Engineer, Lightfield

• Strong software engineering fundamentals
• Experience owning production data systems where query plans, replication lag, backfills, data freshness, schema evolution, or data correctness had real user-facing consequences
• Comfort debugging across multiple layers of the stack
• Good judgment about when to make a tactical fix and when to invest in a more durable platform or architecture change
• Product orientation: you care about how data infrastructure decisions affect customers, users, and engineering velocity
• Clear communication, strong ownership, and a bias toward practical tradeoffs

Desirable

• We're building the infrastructure foundation for a fast-growing AI product company serving thousands of customers:
• Our Postgres fleet serves 5B+ queries a month — roughly 2,500 QPS steady state, with sustained spikes past 25,000 QPS — and database workload more than doubled last month
• Redis sustains ~50,000 commands per second behind a job platform that executes 10M+ background job runs a day across ~170 queues
• We ingest tens of millions of emails and calendar events a month
• That growth creates scaling pressure across backend systems, infrastructure, and data infrastructure
• We're hiring a staff-level engineer who spikes in data infrastructure but is excited to work across backend systems, infrastructure, and product-facing data problems
• The work is close to the product, close to customers, and close to production
• As a Software Engineer, Data Infrastructure, you'll build the next generation of our data systems
• We got remarkably far on a deliberately simple stack: Postgres as the system of record, a sharded transactional outbox for change events, Redis-buffered sync into Typesense for search, BullMQ for processing, and Postgres-backed customer-facing analytics with per-organization row-level security
• The next phase is evolving that pragmatic foundation into best-practice data architecture: change data capture, event modeling, schema design, query performance, freshness guarantees, and the right boundary between transactional and analytical workloads
• The system of record itself is unusual
• Customers define their own objects, attributes, and relationships at runtime, so the core data model is a schema-flexible, graph-shaped store: entity-attribute-value with typed edges, versioned attribute values, and relationship history
• That makes schema design, indexing, and query performance genuinely hard problems rather than routine tuning
• The surface area is wider than analytics: customer-facing dashboards, historical and audit data, datasets that power pipeline-generation products, and evaluation data that measures our AI agents
• This is data infrastructure work, not a BI or dashboarding role
• It's a good fit for someone who likes high-volume data systems, pragmatic architecture decisions, and building foundations that product and engineering teams can actually depend on
• This role can be based in San Francisco or Cambridge. In San Francisco, you'd work from our HQ alongside the founders and most of the engineering team. In Cambridge, you'd join an initial group of staff-level engineers at our new, infrastructure-focused Kendall Square site, working alongside one of our most senior infrastructure engineers. We aim to build the site and organization around this group as the company scales
• Scale the analytics engine behind customer-facing dashboards, tackling query performance under row-level security, workload isolation, read architecture, and observability as data volume grows
• Design the ingestion paths, event models, schemas, and query patterns that move data from transactional writes into search, dashboards, and history—with clear guarantees around freshness, correctness, replay, and failure recovery
• Evolve our schema-flexible, graph-shaped data model so customer-defined objects, attributes, and relationships remain fast to query as their size and complexity grow
• Build the foundations for historical reporting and auditability, including attribute versioning, relationship history, and change capture
• Build reliable data systems for usage metering, pipeline generation, and AI evaluation, where errors have direct customer, product, or financial consequences
• Decide when our existing architecture remains the right foundation and when new analytical, streaming, or workflow systems earn their added complexity
• Set the technical direction, abstractions, ownership boundaries, and engineering practices for data systems as the company grows
• What your first year looks like
• Scaling the analytics serving path behind customer-facing dashboards is the anchor project, but the work stays close to the product. The current slate also includes:
• Zero-downtime schema migrations for an 18-collection Typesense search deployment
• A usage-metering pipeline for consumption billing
• Historical and audit data modeling
• Evaluation data infrastructure for our AI agents
• Expect a first year that mixes foundational data systems with product-shaped projects, with the scope to own the technical direction for how data is modeled, moved, and served across Lightfield—and to shape the architecture, abstractions, and team we build as the company scales
• You'd be building our analytical data architecture from close to the beginning — the foundations are deliberately simple, and the architecture that scales them is yours to shape. Customer-facing data products are on the roadmap, database workload more than doubled last month, and the foundations you build will carry the company for years