sprs: sparse matrices for Rust, with a Cholesky you have to opt into

What the library actually covers

sprs implements some sparse matrix data structures and linear algebra algorithms in pure Rust, and it says so without embellishment. The word some is doing work, since the library is not trying to be a general linear algebra suite.

The structures are three: a CSR/CSC matrix, which covers both compressed row and compressed column formats, a triplet matrix, which is the coordinate format, and a sparse vector. The triplet format matters more than it looks, because it is the natural input format and conversion from triplets to a compressed form is the standard first step in a sparse pipeline.

The operations list is the arithmetic you would expect from such a library: sparse matrix with sparse vector product, sparse matrix with sparse matrix product, sparse matrix addition and subtraction, sparse vector addition, subtraction and dot product, and sparse with dense matrix operations.

The algorithms section is where the library earns its place, and it is only four items: an outer iterator on compressed sparse matrices, sparse vector iteration, joint non-zero iterations across sparse vectors, and sparse triangular solves with a dense right-hand side. That last one is the workhorse. A triangular solve is what you need inside a preconditioner or an iterative solver, and having it without leaving the sparse data structure avoids a densification step in the middle of an algorithm.

The one entry with a footnote is a simple sparse Cholesky decomposition, which requires opting into an LGPL license. The README lists it as requiring opting into an LGPL license, which is a licensing decision rather than a technical one, and it is the one feature in the list that is not available by default.

The crate is on crates.io, the primary language is Rust, the licence is Apache-2.0 as recorded on the repository, and the last push was on 2026-10-20 with the project not archived. The repository publishes no GitHub releases, so the changelog is a file, changelog.rst, rather than a release feed.

Building a matrix, and the format the constructors expect

The examples in the README are short enough to read in full, and they teach the API by showing how a compressed matrix is put together.

  use sprs::{CsMat, CsMatOwned, CsVec};
  let eye : CsMatOwned<f64> = CsMat::eye(3);
  let a = CsMat::new_csc((3, 3),
                         vec![0, 2, 4, 5],
                         vec![0, 1, 0, 2, 2],
                         vec![1., 2., 3., 4., 5.]);

Three arguments go into new_csc: the shape as a pair, then two index vectors and a value vector. In compressed column format the first index vector is the column pointers, the second is the row indices of the non-zeros within each column, and the third holds the values in the same order. The sizes line up: five non-zeros, five values, and a column pointer vector whose last entry, 5, is the total number of stored values.

Two details are worth noticing. The type is CsMatOwned<f64>, so the ownership and the element type are part of the type, which means the compiler will stop you mixing a f32 matrix with a f64 one in most operations. And the identity matrix comes from CsMat::eye(3), which is a constructor rather than something you assemble by hand.

The example uses CSC while the feature list leads with CSR and CSC, and both are the same type with a different interpretation of the two index vectors, which is why the constructor is named for the format rather than for the layout. A sparse vector follows the same pattern with a length, an index vector and a value vector, and the example constructs one directly with CsVec::new.

Multiplication, and the identity check the examples use

The arithmetic examples are the second and third code blocks, and between them they show both the operator syntax and the convention for asserting on results.

Matrix and vector multiplication:

  use sprs::{CsMat, CsVec};
  let eye = CsMat::eye(5);
  let x = CsVec::new(5, vec![0, 2, 4], vec![1., 2., 3.]);
  let y = &eye * &x;
  assert_eq!(x, y);

The multiplication operator is overloaded for the sparse and dense combinations, and the references are needed on the operands because the implementation is on the reference type. The result y is a sparse vector, and the assertion checks it against x, which is the point of multiplying by an identity: the result is the input.

Matrix and matrix multiplication with addition:

  use sprs::{CsMat, CsVec};
  let eye = CsMat::eye(3);
  let a = CsMat::new_csc((3, 3),
                         vec![0, 2, 4, 5],
                         vec![0, 1, 0, 2, 2],
                         vec![1., 2., 3., 4., 5.]);
  let b = &eye * &a;
  assert_eq!(a, b.to_csr());

The same identity multiplication is done against a matrix, and the assertion compares a with the result converted to CSR with to_csr(). That conversion call is a real part of the API surface rather than a detail, because a compressed matrix can be stored either way and the format is not part of the type, so equality between two matrices of different formats has to go through an explicit conversion.

The README also points at a more complete example, the heat diffusion example at sprs/examples/heat.rs, which is the sensible next step for anyone who wants to see the library used for something with a physical interpretation rather than for arithmetic tests.

The documentation is on docs.rs, and the sparse vector iteration and joint non-zero iteration entries in the algorithm list are what make the library usable for a real sparse pipeline rather than just a set of operations.

The LGPL Cholesky, and why it is a feature flag

The sparse Cholesky decomposition is the one capability in the library with a licensing condition attached, and the condition is stated plainly in the features list: it requires opting into an LGPL license.

That is a deliberate structural choice, and the reason is the usual one. A Cholesky factorisation of a sparse matrix depends on a sparse LDL or similar implementation, and the well-known ones in this space carry LGPL terms. Rather than pull that into the main crate, the library puts it behind an opt-in feature, so a project that only needs the data structures and the arithmetic can depend on sprs without taking on those terms at all.

The repository layout shows how that is arranged. The workspace members in Cargo.toml are sprs itself, sprs-ldl, sprs-rand, sprs-benches and sprs-tests, and a whole group of suitesparse_bindings members: suitesparse_ldl_sys, sprs_suitesparse_ldl, suitesparse_camd_sys, sprs_suitesparse_camd, suitesparse-src, suitesparse_umfpack_sys and sprs_suitesparse_umfpack. The names ending in _sys are the raw FFI bindings, the ones without are the Rust wrappers, and suitesparse-src is the vendored SuiteSparse source the bindings compile against. There is a .gitmodules file at the root, so the SuiteSparse source is a submodule.

The practical effect is that enabling the Cholesky pulls in a compiled C library and a build step, which is exactly why it is not on by default. If your project needs a sparse factorisation and you are compiling SuiteSparse anyway, this is a maintained Rust binding to it. If you do not, the default build stays pure Rust.

The system dependency is worth flagging to anyone evaluating: a C library with a build step changes what you can ship, particularly in a cross-compilation or musl build, and that is a different adoption profile from a pure Rust crate.

Version policy, licence and the caveat about the API

Two things in the README deserve to be read before you plan around this library.

The first is the API caveat. The API is a work in progress, and feedback on its rough edges is highly appreciated. That is an unusually frank statement for a library with a long history, and it is worth taking at face value: the algorithms are stable, but the interface around them is still moving.

The second is the minimum supported Rust version, currently 1.64. And there is a condition attached: prior to a 1.0 version, bumping the MSRV will not be considered a breaking change, but breakage will be avoided on a best effort basis. So the floor can move without a major version bump, and your build might start failing on a dependency update without a semver major. That is normal for a pre-1.0 crate and is worth factoring into how you pin dependencies.

The licence is the standard Rust dual licence, at your option between the Apache License Version 2.0 and the MIT license, with LICENSE-APACHE and LICENSE-MIT files in the root. The contribution section states the same thing: unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions. The contribution guidelines are in Guidelines.rst, and the rustfmt.toml file at the root holds the formatting configuration.

So the summary is: a well-scoped, pure Rust sparse library with a good set of algorithms, an API that is still being shaped, a pre-1.0 MSRV policy, and one powerful feature that comes with a licence flag and a native build.

Editorial conclusion

Adopt sprs if you are doing sparse linear algebra in Rust and want the data structures, the arithmetic and the triangular solves in one pure Rust dependency rather than reaching for a C library through FFI. Do not adopt it expecting a finished API, because the README says plainly that the API is a work in progress, and do not assume the version number protects you, because the MSRV can be raised below 1.0 without a breaking change. Before you commit, read the MSRV policy against the toolchain your CI pins, check whether enabling the sparse Cholesky pulls a SuiteSparse build into your release pipeline, and run the heat diffusion example at sprs/examples/heat.rs to see the library used on a real problem rather than on an identity multiplication.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. sparsemat/sprs on GitHub