The database architect who rewrote parts of PostgreSQL is now rewriting how global brokerage works. His company, named after an alpaca spotted on a Silicon Valley estate, controls 94% of the world's tokenized US equities market.
Somewhere in Woodside, California, a billionaire keeps alpacas. In 2015, Hitoshi Harada and Yoshi Yokokawa drove past that estate and decided to name their company after the animals they saw. It was a deliberate joke on the coldness of traditional finance - something warm, something alive. A decade later, Alpaca has $1.15 billion in valuation and 94% of the global tokenized US equities market. The alpacas, presumably, remain unimpressed.
Harada arrived in Silicon Valley with a peculiar combination of skills: he knew how databases worked at the deepest level, and he knew that financial data was one of the hardest data problems in existence. Before Alpaca, he spent years at Greenplum - Silicon Valley's first parallel distributed database company - designing MPP database systems from scratch. Parallel query execution. Distributed transactions. Replication systems. Storage optimization. The things that make databases fast when millions of records need answers in milliseconds.
He also, quietly, contributed to PostgreSQL - the open-source database powering a significant portion of the modern internet. His name is in the commit history for Window Functions and CTEs, shipped in PostgreSQL 8.4 through 9.1. He wrote PL/v8, the extension that lets PostgreSQL run JavaScript via Google's V8 engine. If you've ever called a SQL window function - OVER (PARTITION BY ...) - there's a non-zero chance you've run Hitoshi Harada's code.
"When demand emerged, Alpaca could do it. Others couldn't."Hitoshi Harada - on Alpaca's ability to offer tokenized equities
The leap from database architecture to fintech co-founder isn't as strange as it sounds. Financial infrastructure is, at its core, a data problem: who owns what, what did it last trade for, what are the rules that govern the transaction, and how do you confirm all of this in milliseconds without losing money or breaking regulations. Harada spent his career building exactly those systems. Alpaca is what happens when someone who built database internals decides to rebuild the plumbing of global markets.
Today Harada holds two unusual titles simultaneously - CTO and CPO. The combination is intentional. At Alpaca, the product is the technology. There is no UX layer that hides the complexity; the customers are developers and financial institutions who talk directly to the API. The person who understands how the system works also needs to understand what users actually need from it. Harada has been clear about his philosophy: "Many features built by developers proved useless because they weren't based on actual customer needs." He built something, then listened to who used it and why.
Alpaca went through Y Combinator's Winter 2019 batch - a notable inflection point in which the company crystallized its developer-first identity. The brokerage-as-API model caught on. Commission-free trading had disrupted retail finance; Alpaca went one layer deeper, making it trivial for other companies to build their own trading products. Robo-advisors, crypto exchanges, fintech apps, hedge funds - if they needed brokerage infrastructure, they could call Alpaca's API instead of applying for a broker-dealer license.
Harada uses a specific analogy when explaining what Alpaca is building: Windows. Not the product, but the concept. Windows abstracted different hardware manufacturers behind a single interface. Developers didn't need to understand whether they were running on IBM or Compaq - they just wrote to the Windows API. Harada wants Alpaca to do the same thing across regulatory jurisdictions. A developer in Brazil or the UAE shouldn't need to understand the particular rules of each country's securities regime - they should just call the Alpaca API.
The tokenization of real-world assets is where this vision gets genuinely interesting. Alpaca's Instant Tokenization Network (ITN) lets users buy shares in traditional securities markets and receive the tokenized version in their wallet within seconds. It sounds simple. It isn't. Corporate actions - dividends, stock splits, rights issues - need to propagate correctly through both the traditional and on-chain versions. The peg between a tokenized stock and the underlying asset needs to hold. Market makers need arbitrage incentives to maintain liquidity.
Most companies claiming to tokenize stocks hadn't actually solved these problems. Alpaca had. "When demand emerged, Alpaca could do it. Others couldn't," Harada said in a 2026 interview. The self-clearing status - obtained after years of regulatory work and the 2024 DTCC transition - was the thing that made it possible. You cannot tokenize equities you don't actually clear.
"Tokenizing RWAs requires proper management of the underlying assets. Equities demand handling of complex corporate actions like dividends and stock splits."Hitoshi Harada
Looking five to ten years ahead, Harada questions whether traditional stock exchanges will remain necessary. He envisions direct on-chain equity issuance with native transparency - companies issuing stock directly onto a chain rather than through an exchange. He's careful to note that brokers remain essential for settlement and trust functions, but the exchange as an intermediary may be a relic waiting for its replacement.
That's a significant claim. It's also one backed by market share numbers that suggest Alpaca isn't just theorizing - it's already executing. Citadel Securities, BNP Paribas, MUFG, and Kraken don't invest in market theory. They invest in infrastructure that works.
"What truly matters now is upgrading real-world assets in a practical way, with equities, particularly US stocks, being the most natural starting point."On tokenization strategy, 2026
"Arbitrage opportunities between traditional and tokenized markets create incentives for market makers. This mechanism - not just capital injection - stabilizes prices."On market liquidity mechanisms
"Many features built by developers proved useless because they weren't based on actual customer needs."On product development philosophy, ODBMS interview
"Rather than solving multiple problems simultaneously, successful products must deliver one good thing as quickly as possible."On focus and strategic discipline
Before billion-dollar valuations, there was code. Harada's open-source legacy is the kind that persists quietly in production systems worldwide, invisible to the people who depend on it. Window functions - RANK(), DENSE_RANK(), LAG(), LEAD(), the entire OVER clause syntax in SQL - he wrote the PostgreSQL implementation. Released in version 8.4. Used in virtually every serious data engineering project since.
PL/v8 is weirder and more interesting. It's a procedural language extension for PostgreSQL that lets you write database functions in JavaScript, executed by Google's V8 engine. The same V8 that runs Chrome and Node.js. It bridges two worlds that have no obvious reason to be connected: the ACID-compliant, transactional world of relational databases and the event-driven, prototype-based world of JavaScript. Harada built that bridge because someone needed to and he could.
At Greenplum, he moved from writing language extensions to designing entire database architectures. Greenplum was a Massively Parallel Processing (MPP) database - data spread across dozens or hundreds of nodes, queries distributed and parallelized across all of them simultaneously. The engineering challenges are qualitatively different from single-node databases: distributed transactions, network partition handling, query planning across distributed data. Harada worked on all of it.
When Pivotal absorbed Greenplum after EMC's acquisition, Harada continued in big data infrastructure. The thread is consistent across his entire career: large-scale data, high-throughput systems, the engineering that makes "fast" mean something at scale.