anyone trying to get into quantum computing or use it to build something is the abundance of SDKs available. Every big company and new startup’s mission is to build a Python package that can be used to either learn the fundamentals of quantum computing or develop an algorithm. But as someone who likes both software and quantum, I like to install multiple packages just to try them and advise people on which one to use for what they want to do.
You search for a tutorial, you install something, then something else. Before you know it, you’ve got Qiskit, Cirq, PennyLane, and maybe even something obscure sitting in your environment… and no real sense of which one you’re supposed to actually use to build whatever application you had in mind when you started. I am writing this article to save you some time.
The truth is (which you may already know), you don’t need all of them. You probably don’t even need two.
The trick isn’t picking the “best” SDK (which I would argue doesn’t exist, not yet anyway), it’s picking the right one for what you’re trying to do.
Quantum SDKs aren’t interchangeable; they’re built with very different priorities: some are education-first, some are hardware-first, some are machine-learning-first, and some are research playgrounds.
Once you see that and have a clear goal in mind, the ecosystem becomes much less confusing. In this article, we will discuss the 4 most used SDKs and generally address other tools that may not be as commonly used.
So, let’s get into it…
Qiskit: The “Default” Starting Point
If you’re not sure where to begin, start here. If you even Google the phrase “quantum computing,” you will find Qiskit in the first page of search results, if not the top 3 results!
Qiskit has become the de facto entry point for a lot of people because it does a few things really well! It offers clean learning resources, access to real quantum hardware, and, most importantly, a large and active ecosystem.
Qiskit feels like a structured environment. You define circuits, you run them, and you get results in a way that mirrors how most people are taught quantum computing. And in many cases, computer science.
To create a simple circuit in Qiskit, you only need a few lines of code:
And just like that, you’ve created a superposition and measured it.
Though Qiskit is good to use for teaching and learning, experimenting with real devices, and standard circuit-based workflows, it still struggles in many ways.
Because the purpose of building Qiskit is to provide a general framework for quantum computing, it is both very general and quite vague, and at times not well-documented, especially for new, application-specific functions. Hence, it can feel a bit heavy, and it is definitely not ideal for gradient-based or ML-heavy workflows.
PennyLane: Built for Quantum Machine Learning
Now let’s switch gears. If your interest in quantum computing involves optimization, gradients, or machine learning, PennyLane is in a different category.
It wasn’t built as a general-purpose SDK. It was built specifically for hybrid quantum-classical workflows.
Most near-term quantum algorithms look like this:
- Prepare a parameterized quantum circuit.
- Run it.
- Measure something.
- Feed that into a classical optimizer.
- Repeat as needed to get the results you want.
This loop is where PennyLane shines.
For example, let us consider the core idea behind quantum machine learning: You have a parameterized quantum circuit, and you can optimize it using gradients. You can simply do that in PennyLane as follows:
That last line is the key to why using PennyLane makes things much easier here.
So, if you want to build an application that involves quantum machine learning, variational algorithms, or gradient-based optimization, PennyLane is the way to go!
Now, you might have noticed that the PennyLane code is not as straightforward and intuitive as Qiskit’s; that is one of the downsides to using it. It may have a slightly higher barrier to entry, and it is less hardware-centric than Qiskit.
Cirq: For When You Want More Control
So far, we have Qiskit for general applications, PennyLane for QML, and now we have Cirq. Cirq sits in an interesting space.
It’s not as beginner-friendly as Qiskit, and it’s not as ML-focused as PennyLane. Instead, it gives you lower-level control over circuits and execution. This makes it popular for algorithm development, research, and hardware-aware circuit design.
Cirq feels closer to the “metal.” You’re thinking more explicitly about qubits, gates, and scheduling.
For example, I can replicate the same circuit we built before with Qiskit, using Cirq as follows:
For me, Cirq is often used when you want fine-grained control over your circuit, need to maintain research workflows, or want clean circuit definitions. Subsequently, because it provides this hardware control, it has a steeper learning curve and less structured onboarding than Qiskit and PennyLane.
It is worth noting that you can achieve the same level of hardware control with Qiskit as with Cirq, with a shallower learning curve.
Amazon Braket: The Multi-Hardware Playground
Last but not least, let’s talk about Braket! Braket is less about how you write circuits and more about where you run them. It gives you access to multiple quantum hardware providers through one interface.
Different hardware platforms behave differently. Today, we have different modalities of qubits: superconducting qubits, trapped ions, and photonic qubits, to name a few. Braket lets you experiment across these without switching ecosystems.
So, if you want hardware access across vendors, cloud-based workflows, or to run experimentation, Braket is your tool of choice. That said, Braket is less opinionated than other SDKs and requires more context to use effectively.
The Ones Most People Forget
This is where things get interesting and narrower! So, let’s see some examples of different ways to deal with quantum technologies.
D-Wave Ocean
So far, we have only discussed gate-based quantum computing! D-Wave’s SDK is built for quantum annealing, not gate-based computing. That means: you don’t build circuits, but you define optimization problems.
Strawberry Fields: Photonic Quantum Computing
Most frameworks assume qubits. Strawberry Fields doesn’t. It works with continuous-variable quantum systems, often used in photonic quantum computing.
qBraid: Bridging the Ecosystem
qBraid tries to solve a real problem: What if you didn’t have to choose just one SDK?
It allows you to convert circuits between frameworks like Qiskit, Cirq, and others.
QuTiP, ProjectQ, and Others
These tools tend to be more academic, more specialized, and somewhat less beginner-friendly.
They’re useful, but not where you should start.
If your goal isStart with…Learning basicsQiskitRunning on real hardwareQiskitQuantum machine learningPennyLaneAlgorithm research / controlCirqTrying multiple hardware backendsAlgorithm research/control
So which one should you use?
To answer that question, you first need to know what you are trying to build! Let’s say you want to build a variational circuit.
If you use Qiskit, you will manually handle parameters, and optimization happens outside the framework.
In PennyLane, parameters and gradients are built in, and it is natural for ML workflows.
If you decide to use Cirq, you gain flexibility and take on more responsibility.
Same idea. Completely different experience. This is why the choice of SDK matters.
If you’re still unsure, here’s a simple recommendation:
- Start with Qiskit if you’re new.
- Start with PennyLane if you care about ML.
- Move to Cirq when you want more control.
And don’t touch anything else yet.
Final thought
I am very aware of how confusing and overwhelming it can be to decide which tool to use, let alone when you are new to a field! Things just get out of control super fast. The quantum ecosystem isn’t confusing because it’s poorly designed. It’s confusing because it’s still evolving. Different tools exist because people are solving different problems using quantum computing.
So the question here is not really “Which SDK is best?”; technically, none of them are meant to be. Instead, the question you should ask yourself to help you decide is “Which SDK fits what I want to do?” Once you have the answer, everything becomes much clearer. And more importantly, you can actually start building.
