Every founder building with AI eventually asks the same questions: Do we need our own model? Which cloud? GPUs or something else? Should we copy ChatGPT\u2019s stack?<\/p>\n
The honest answer is the same one that shows up when you study Netflix or WhatsApp: it depends<\/strong>. And there is no better proof than looking at what the world\u2019s most famous AI products are actually built with.<\/p>\n ChatGPT, Gemini, Claude, Perplexity and Midjourney all look like \u201cAI apps\u201d from the outside. Under the hood, they solve different problems \u2014 conversation at planetary scale, multimodal models on custom chips, multi-cloud inference, real-time web search, and creative image generation through a community platform. Their stacks reflect those problems, not a universal AI template.<\/p>\n Here is what each is built with, based on company blogs, cloud case studies, research papers and official engineering disclosures \u2014 and the lesson behind each choice.<\/p>\n ChatGPT is the product that made generative AI mainstream. The public story is \u201clarge language models.\u201d The engineering story is inference systems, data stores and streaming pipelines under extreme growth.<\/p>\n OpenAI\u2019s own job postings and engineering context describe a Python-heavy stack. Model inference runs through a service wrapping PyTorch<\/strong> transformers. Core technologies repeatedly cited include Python, PyTorch, CUDA, Triton, Redis<\/strong>, high-speed GPU networking (InfiniBand, NCCL, NVLink<\/strong>), plus FastAPI<\/strong>, Terraform<\/strong>, Buildkite<\/strong>, Kafka<\/strong> and databases such as Postgres<\/strong> and Cosmos DB<\/strong>. At the centre of the infrastructure is a large deployment of GPU nodes across dozens of Kubernetes<\/strong> clusters in multiple regions \u2014 primarily on Microsoft Azure<\/strong>.<\/p>\n The most surprising public detail is not the GPUs. It is the database. In January 2026, OpenAI published Scaling PostgreSQL to power 800 million ChatGPT users<\/em>. Over the prior year, PostgreSQL load grew more than 10x. ChatGPT and the API still relied on a single primary Azure PostgreSQL flexible server<\/strong> for writes, with nearly 50 globally distributed read replicas<\/strong>, serving millions of queries per second for hundreds of millions of users. OpenAI moved newer, shardable, write-heavy workloads to Azure Cosmos DB<\/strong>, while keeping hard-to-shard systems on Postgres with aggressive optimisation, pooling and caching.<\/p>\n For event streaming and data pipelines, OpenAI engineering has described a platform centred on Apache Kafka<\/strong> and PyFlink<\/strong> on Kubernetes \u2014 chosen specifically so Python remains the default language across research and production streaming work.<\/p>\n The lesson:<\/strong> an AI product is not only a model. At ChatGPT scale, the hard problems include inference efficiency, read-heavy product databases, and Python-friendly infrastructure that researchers and product engineers can actually operate. \u201cBoring\u201d Postgres still sits under one of the most advanced consumer AI apps in the world.<\/p>\n Gemini is Google\u2019s flagship multimodal model family. Unlike most startups buying NVIDIA capacity from a cloud marketplace, Gemini was designed around Google\u2019s own accelerators and compilers.<\/p>\n Google\u2019s Gemini technical report describes Transformer-based models trained and optimised for inference on Tensor Processing Units (TPUs)<\/strong>. Training used TPUv4<\/strong> and TPUv5e<\/strong> fleets depending on model size. Gemini Ultra training used a large TPUv4 fleet across multiple datacentres. TPUv4 \u201cSuperPods\u201d contain thousands of chips connected through high-speed interconnects; Google combines SuperPods across datacentres using its internal network, with model parallelism inside a SuperPod and data parallelism across SuperPods.<\/p>\n On the software side, Google\u2019s production AI stack centres on JAX<\/strong>, compiled through XLA<\/strong>, with distributed partitioning via systems such as GSPMD<\/strong> and the Pathways<\/strong> runtime. Google\u2019s developer materials describe the broader \u201cJAX AI Stack\u201d \u2014 JAX, Flax, Optax, Orbax \u2014 co-designed with TPU hardware so researchers can write Python-like code that compiles into efficient accelerator programs. Product surfaces such as the Gemini app and AI Mode in Search then sit on top of Google\u2019s wider serving and cloud infrastructure.<\/p>\n The lesson:<\/strong> when you own the full stack \u2014 chips, compilers, datacentre network and model code \u2014 you can co-design hardware and software instead of renting a generic GPU box. Most companies cannot (and should not) copy this. The transferable idea is narrower: treat model performance as a systems problem, not only a research problem.<\/p>\n Claude\u2019s public brand is safety and useful assistants. Anthropic\u2019s infrastructure story is diversification.<\/p>\n Anthropic has publicly described a deliberate multi-platform compute strategy across Amazon Trainium<\/strong>, Google TPUs<\/strong> and NVIDIA GPUs<\/strong> (with later disclosures also referencing broader accelerator partnerships). AWS is repeatedly positioned as a primary training and cloud partner, including large Trainium deployments and Claude availability through Amazon Bedrock<\/strong>. Separately, Anthropic expanded Google Cloud TPU capacity and has discussed serving Claude inference on Google Kubernetes Engine (GKE)<\/strong> with accelerator node pools. Claude is also available across major clouds, including Bedrock, Vertex AI and Azure.<\/p>\n Google Cloud has also published how Anthropic moves training and inference telemetry across AWS and Google Cloud using services such as Pub\/Sub<\/strong>, with private connectivity for sensitive research workloads.<\/p>\n The lesson:<\/strong> at frontier-model scale, compute supply risk is existential. Anthropic\u2019s stack is not \u201cpick one cloud and one chip.\u201d It is an orchestration and efficiency problem across multiple accelerator families \u2014 so product availability does not depend on a single supplier\u2019s capacity cycle.<\/p>\n Perplexity looks like a chatbot. Architecturally, it is closer to a modern search engine with an LLM on top.<\/p>\n In its own engineering write-up on the Search API, Perplexity describes production search infrastructure handling about 200 million daily queries<\/strong>, with an exabyte-scale index, hybrid lexical + semantic retrieval, multi-stage ranking, and dynamic content understanding. Crawler and indexing fleets are described as tens of thousands of CPUs and hundreds of terabytes of RAM, with warm\/cold storage decisions driven by models and heuristics.<\/p>\n For the retrieval engine itself, Vespa.ai has published that Perplexity builds AI search at scale on Vespa<\/strong> \u2014 indexing billions of pages and files as text, vectors and metadata, then retrieving and scoring candidates fast enough to feed an LLM with citations.<\/p>\n On the model and cloud side, AWS case studies describe Perplexity running on AWS<\/strong>, using foundational cloud services, Amazon Bedrock<\/strong> for Claude models, SageMaker<\/strong> and GPU instances such as EC2 P4de for training\/fine-tuning, alongside Perplexity\u2019s own models (Sonar family). Anthropic\u2019s customer materials similarly note Perplexity routing across Claude model tiers for cost\/latency tradeoffs. Perplexity\u2019s docs also describe multi-provider orchestration across OpenAI, Anthropic, Google, xAI and its own models.<\/p>\n The lesson:<\/strong> if your product promise is \u201canswers with sources,\u201d the differentiating stack is retrieval, ranking and indexing \u2014 not only which frontier model you call. Models are swappable. Search quality is the moat.<\/p>\n Midjourney\u2019s growth story is one of the strangest and most instructive in AI. For a long time, the product experience lived primarily inside Discord<\/strong>: users typed Discord\u2019s own case study describes how Midjourney used Discord APIs for real-time progress edits and public sharing \u2014 turning generation wait time into a social reveal. Discord engineering later documented the \u201cMaxjourney\u201d work required to support Midjourney-scale communities, including mega-servers with enormous concurrent online populations.<\/p>\n Behind that chat UI, Midjourney\u2019s compute story is more conventional AI infrastructure. A 2023 Google Cloud announcement quoted founder David Holz saying Midjourney trained algorithms on TPU v4 with JAX<\/strong> and ran inference on huge clusters of GPUs<\/strong> on Google Cloud. Midjourney\u2019s own docs make the product economics explicit: subscriptions buy GPU time<\/strong> (Fast \/ Relax \/ Turbo), because image and video generation are accelerator-bound workloads.<\/p>\n The lesson:<\/strong> you do not always need to invent the distribution layer. Midjourney shipped creativity through an existing social platform and concentrated engineering on model quality, GPU scheduling and community mechanics. Distribution can be borrowed. Compute cannot.<\/p>\n Looking across ChatGPT, Gemini, Claude, Perplexity and Midjourney, five patterns matter more than any single framework choice.<\/p>\n 1. AI apps are systems, not demos.<\/strong> The model is necessary but not sufficient. Databases, queues, caches, retrieval layers, accelerator scheduling and observability decide whether the product feels instant or broken.<\/p>\n 2. There is no universal AI stack.<\/strong> OpenAI leans on Azure + GPUs + Python services. Google co-designs around TPUs + JAX. Anthropic spreads risk across Trainium, TPUs and GPUs. Perplexity invests in search. Midjourney paired Discord distribution with Google Cloud accelerators.<\/p>\n 3. \u201cBoring\u201d data systems still win.<\/strong> OpenAI\u2019s public Postgres story is the clearest example. Frontier models did not remove the need for careful relational engineering; they amplified it.<\/p>\n 4. Product shape drives architecture.<\/strong> Chat products optimise for session state and inference latency. Answer engines optimise for retrieval. Image tools optimise for GPU queues and UX during wait time. Copy the product shape, not a random competitor\u2019s repo.<\/p>\n 5. Start with leverage, then specialise.<\/strong> Most teams should begin with a strong API model, a clean application backend, solid observability and a retrieval strategy if facts matter. Build custom training clusters only when the business truly requires it.<\/p>\n At Onclick Innovations, we do not pretend every client needs a private foundation model or a thousand-GPU cluster. Most successful AI products we see start with a clear workflow, reliable application engineering, and disciplined use of model APIs \u2014 then add retrieval, tools, evaluation and scaling controls as real usage demands it.<\/p>\n The companies in this article prove the same point at extreme scale: technology choices should follow the actual problem. ChatGPT\u2019s problem is serving conversation and platform load globally. Gemini\u2019s problem includes co-designed training at Google scale. Claude\u2019s problem includes compute resilience. Perplexity\u2019s problem is trustworthy search. Midjourney\u2019s problem is creative generation plus community distribution.<\/p>\n If you are planning an AI product \u2014 chatbot, search assistant, internal copilot, or creative tool \u2014 we can help you choose an architecture that fits your stage, not someone else\u2019s press release.<\/p>\n OpenAI publicly describes a Python-centred production environment with PyTorch inference, Kubernetes GPU clusters on Azure, Kafka\/streaming systems, Redis and related services. A 2026 OpenAI engineering post also explains how Azure PostgreSQL (single primary + many read replicas) powers major ChatGPT\/API workloads for hundreds of millions of users, with shardable writes moving toward Cosmos DB.<\/p>\n Google\u2019s Gemini report and infrastructure materials describe training and serving around TPUs, with software based on JAX, XLA and Pathways-style distributed runtimes \u2014 a vertically integrated Google stack rather than a generic rented GPU setup.<\/p>\n Anthropic has disclosed a multi-cloud accelerator strategy spanning Amazon Trainium, Google TPUs and NVIDIA GPUs, with AWS as a major training\/cloud partner and Claude also served through platforms such as Bedrock and Google Cloud infrastructure including GKE for inference workloads.<\/p>\n No. Perplexity\u2019s own engineering materials emphasise large-scale search indexing, hybrid retrieval and multi-stage ranking. Vespa and AWS case studies describe search\/retrieval infrastructure and multi-model serving, including Claude via Bedrock and Perplexity\u2019s own models.<\/p>\n Product interaction historically centred on Discord bots and community servers, while Google Cloud materials state Midjourney trained with JAX on TPUs and ran inference on large GPU clusters. Midjourney\u2019s docs frame subscriptions around GPU time.<\/p>\n No. These stacks were shaped by extreme scale, proprietary chips, or specialised product bets. Startups should begin with proven application frameworks, managed model APIs, strong evaluation\/observability, and retrieval where needed \u2014 then evolve under real load.<\/p>\nChatGPT (OpenAI): Python, Azure, Kubernetes \u2014 and a lot of PostgreSQL<\/h2>\n
Gemini (Google DeepMind): TPUs, JAX, XLA and Pathways<\/h2>\n
Claude (Anthropic): multi-cloud compute as strategy<\/h2>\n
Perplexity: search infrastructure first, models second<\/h2>\n
Midjourney: Discord as the product surface, Google Cloud as the factory<\/h2>\n
\/imagine<\/code>, watched images appear through message updates, and learned prompt craft in public channels.<\/p>\nWhat these five AI stacks teach founders and CTOs<\/h2>\n
How Onclick Innovations thinks about AI product architecture<\/h2>\n
FAQ<\/h2>\n
What tech stack does ChatGPT use?<\/h3>\n
What powers Google Gemini under the hood?<\/h3>\n
Where does Claude run?<\/h3>\n
Is Perplexity just a wrapper around GPT or Claude?<\/h3>\n
What is Midjourney built on?<\/h3>\n
Should a startup copy these AI stacks?<\/h3>\n