Vector Quantization uses a look-up table principle. The look-up table contains small image parts (for example 2 by 2 pixels). The original image is constructed like a puzzle from these small image parts. The collection of image parts is called the codebook. For each image a special optimized codebook has to be generated. The code book can contain 64 (6 bits) or 256 (8 bits) parts. The size of the small image parts can be 2 by 2 pixels or 3 by 3 pixels. The image parts can be defined in 16 or 24 bit color and can contain an alpha values next to red, green and blue values.

Let's illustrate this with an example. Suppose we have an image of 128 by 128 pixels in 24 bit color. First we will have to generate the codebook. This is done by using a special optimized program that will search for image parts. Since we have only 256 different parts we will have to re-use the parts at a different place in the image. It's like using the same puzzle piece at several places. The special program is very good at looking for puzzle pieces that can be re-used. Naturally the puzzle piece doesn't fit perfectly all the time and this means that there will be small errors in the final image. This however means that Vector Quantization is usually a lossy compression algorithm because the compressed image is not identical with the original image after decompression. 

There are 2 parameters that can influence the compression: the blocksize (2 by 2 or 3 by 3) and the size of the lookup table.

During decoding, first we receive index of block in the lookup table and then read color values from the table.

Analysis

Vector Quantization has a simple decoding algorithms and provides direct/random access to textures.

But because it relies on using a code book, the decoder needs to do two memory accesses to decode each texel/block. The first memory read is needed to read the index/block code - the index into the palette/code book. The second access is needed to look up the texel values associated with the index/block code, by using the index to look that up in the code book. 

The code book could theoretically be stored on-chip to avoid the second memory reference, but since this would be costly, it's not done. Plus, even if the palette/code book were stored on-chip, it would need to be loaded and that would have a significant performance impact as well. For palletizing new palette should be renewed for each new texture.
Codebook transfer costs 256*4*8*3~24K bits per texture. For usual textures (64*64) that leads to transfer of 6 bits per texel. Additionally during texture mapping we should transfer 8 bit table index per texel  (8 BPT). Therefore totally 14 bits per pixel are transferred, that gives us transfer compression ratio only 1.5x. 

The only solution is to transfer only necessary look-up table entries. During texture mapping, we can transfer via AGP block indexes and check was this index placed in look-up table in video memory. If yes, we read it from this table, otherwise we transfer this entry via AGP from RAM. This approach allows to increase transfer compression ratio in case if we transfer uniform part of texture, but it leads to additional  (3rd) memory access to check cash entry, and if we need to transfer whole texture, we need to transfer all codebook.

For these reasons, VQ is much slower than Block Decomposition and average transfer compression rate of VQ is about 2.5x only. 

Concerning image quality, Vector Quantization can handle sharp edges very well, the code book will contain blocks that represent sharp edges. Color  graduations are a bigger risk since they need lots of code book entries with very little color changes. Usually there is room in the code book for one color graduation, lets say from blue to red. If the code book is too small then you will get banding in the color graduation.